Skip to content
This repository has been archived by the owner on Mar 22, 2023. It is now read-only.

Commit

Permalink
Improvement: Added the Note for External applications. (kubernetes#39691
Browse files Browse the repository at this point in the history
)

* Improvement: Added the word External applications.

* Added the Note for External Applications.

* Modify the note
  • Loading branch information
Shubham82 authored Mar 22, 2023
1 parent 112bdf1 commit 458c0e3
Showing 1 changed file with 13 additions and 2 deletions.
15 changes: 13 additions & 2 deletions content/en/docs/concepts/security/service-accounts.md
Original file line number Diff line number Diff line change
Expand Up @@ -178,14 +178,25 @@ following methods:
rotates the token before it expires.
* [Service Account Token Secrets](/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token)
(not recommended): You can mount service account tokens as Kubernetes
Secrets in Pods. These tokens don't expire and don't rotate. This method
is not recommended, especially at scale, because of the risks associated
Secrets in Pods. These tokens don't expire and don't rotate.
This method is not recommended, especially at scale, because of the risks associated
with static, long-lived credentials. In Kubernetes v1.24 and later, the
[LegacyServiceAccountTokenNoAutoGeneration feature gate](/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features)
prevents Kubernetes from automatically creating these tokens for
ServiceAccounts. `LegacyServiceAccountTokenNoAutoGeneration` is enabled
by default; in other words, Kubernetes does not create these tokens.

{{< note >}}
For applications running outside your Kubernetes cluster, you might be considering
creating a long-lived ServiceAccount token that is stored in a Secret. This allows authentication, but the Kubernetes project recommends you avoid this approach.
Long-lived bearer tokens represent a security risk as, once disclosed, the token
can be misused. Instead, consider using an alternative. For example, your external
application can authenticate using a well-protected private key `and` a certificate,
or using a custom mechanism such as an [authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) that you implement yourself.

You can also use TokenRequest to obtain short-lived tokens for your external application.
{{< /note >}}

## Authenticating service account credentials {#authenticating-credentials}

ServiceAccounts use signed
Expand Down

0 comments on commit 458c0e3

Please sign in to comment.