@@ -188,10 +188,10 @@ by a `/`. For example: `cloud-hosting.example.net/cloud-api-credentials`.
188
188
189
189
# ## Opaque Secrets
190
190
191
- ` Opaque` is the default Secret type if omitted from a Secret configuration file.
192
- When you create a Secret using `kubectl`, you will use the `generic`
193
- subcommand to indicate an `Opaque` Secret type. For example, the following
194
- command creates an empty Secret of type `Opaque` :
191
+ ` Opaque` is the default Secret type if you don't explicitly specify a type in
192
+ a Secret manifest. When you create a Secret using `kubectl`, you must use the
193
+ ` generic ` subcommand to indicate an `Opaque` Secret type. For example, the
194
+ following command creates an empty Secret of type `Opaque` :
195
195
196
196
` ` ` shell
197
197
kubectl create secret generic empty-secret
@@ -212,30 +212,25 @@ In this case, `0` means you have created an empty Secret.
212
212
213
213
A `kubernetes.io/service-account-token` type of Secret is used to store a
214
214
token credential that identifies a
215
- {{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}.
216
-
217
- {{< note >}}
218
- Versions of Kubernetes before v1.22 automatically created credentials for
219
- accessing the Kubernetes API. This older mechanism was based on creating token
220
- Secrets that could then be mounted into running Pods.
221
- In more recent versions, including Kubernetes v{{< skew currentVersion >}}, API
222
- credentials are obtained directly by using the
223
- [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
224
- API, and are mounted into Pods using a
225
- [projected volume](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume).
226
- The tokens obtained using this method have bounded lifetimes, and are
227
- automatically invalidated when the Pod they are mounted into is deleted.
228
-
229
- You can still
230
- [manually create](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
231
- a ServiceAccount token Secret; for example, if you need a token that never
232
- expires. However, using the
233
- [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
234
- subresource to obtain a token to access the API is recommended instead.
235
- You can use the
236
- [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
237
- command to obtain a token from the `TokenRequest` API.
238
- {{< /note >}}
215
+ {{< glossary_tooltip text="ServiceAccount" term_id="service-account" >}}. This
216
+ is a legacy mechanism that provides long-lived ServiceAccount credentials to
217
+ Pods.
218
+
219
+ In Kubernetes v1.22 and later, the recommended approach is to obtain a
220
+ short-lived, automatically rotating ServiceAccount token by using the
221
+ [`TokenRequest`](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/)
222
+ API instead. You can get these short-lived tokens using the following methods :
223
+
224
+ * Call the `TokenRequest` API either directly or by using an API client like
225
+ ` kubectl` . For example, you can use the
226
+ [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-)
227
+ command.
228
+ * Request a mounted token in a
229
+ [projected volume](/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume)
230
+ in your Pod manifest. Kubernetes creates the token and mounts it in the Pod.
231
+ The token is automatically invalidated when the Pod that it's mounted in is
232
+ deleted. For details, see
233
+ [Launch a Pod using service account token projection](/docs/tasks/configure-pod-container/configure-service-account/#launch-a-pod-using-service-account-token-projection).
239
234
240
235
{{< note >}}
241
236
You should only create a ServiceAccount token Secret
0 commit comments