Skip to content

Commit 458c0e3

Browse files
authored
Improvement: Added the Note for External applications. (#39691)
* Improvement: Added the word External applications. * Added the Note for External Applications. * Modify the note
1 parent 112bdf1 commit 458c0e3

File tree

1 file changed

+13
-2
lines changed

1 file changed

+13
-2
lines changed

content/en/docs/concepts/security/service-accounts.md

Lines changed: 13 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -178,14 +178,25 @@ following methods:
178178
rotates the token before it expires.
179179
* [Service Account Token Secrets](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
180180
(not recommended): You can mount service account tokens as Kubernetes
181-
Secrets in Pods. These tokens don't expire and don't rotate. This method
182-
is not recommended, especially at scale, because of the risks associated
181+
Secrets in Pods. These tokens don't expire and don't rotate.
182+
This method is not recommended, especially at scale, because of the risks associated
183183
with static, long-lived credentials. In Kubernetes v1.24 and later, the
184184
[LegacyServiceAccountTokenNoAutoGeneration feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features)
185185
prevents Kubernetes from automatically creating these tokens for
186186
ServiceAccounts. `LegacyServiceAccountTokenNoAutoGeneration` is enabled
187187
by default; in other words, Kubernetes does not create these tokens.
188188

189+
{{< note >}}
190+
For applications running outside your Kubernetes cluster, you might be considering
191+
creating a long-lived ServiceAccount token that is stored in a Secret. This allows authentication, but the Kubernetes project recommends you avoid this approach.
192+
Long-lived bearer tokens represent a security risk as, once disclosed, the token
193+
can be misused. Instead, consider using an alternative. For example, your external
194+
application can authenticate using a well-protected private key `and` a certificate,
195+
or using a custom mechanism such as an [authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) that you implement yourself.
196+
197+
You can also use TokenRequest to obtain short-lived tokens for your external application.
198+
{{< /note >}}
199+
189200
## Authenticating service account credentials {#authenticating-credentials}
190201

191202
ServiceAccounts use signed

0 commit comments

Comments
 (0)