New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Removing need to have service account tokens in etcd AKA 'dynamic secrets' #48408
Comments
We are very incentivized in the very short term to address the secret duplication problem (we're hitting scale limits that we have to solve in some fashion) - I'd prefer to take some baby steps to dynamic secrets. |
@kubernetes/sig-auth-feature-requests |
Issues go stale after 90d of inactivity. Prevent issues from auto-closing with an If this issue is safe to close now please do so with Send feedback to sig-testing, kubernetes/test-infra and/or |
/remove-lifecycle stale |
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. implement ServiceAccountTokenProjection design here: kubernetes/community#1973 part of #61858 ```release-note Add a volume projection that is able to project service account tokens. ``` part of #48408 @kubernetes/sig-auth-pr-reviews @kubernetes/sig-storage-pr-reviews
@liggitt: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Today we generate a service account token into etcd for every service account created. A controller watches for new service accounts, generates the token as a secret, and then links the secret to the service account. The secret must contain a
ca.crt
, atoken
, and optionally anamespace
for use in contacting the apiserver. An admission controller then automatically mounts that token (unless requested otherwise) into every pod that runs that service account. This is a stable API for clients that must be preserved.The token is a JWT signed token that identifies the secret name, UID, service account name, namespace, and a few other values. It does not expire (but can be expired by a user by deleting the secret). The ca.crt is admin controlled, but can potentially be large, and is identical for almost all clients.
Some integrations may take the service account token and transform it - OpenShift does so to generate pull secrets to an integrated registry, I've seen it used to generate other cryptographic entities.
Challenges today:
ca.crt
is large, most of the data is duplicated, and so on dense clusters (O(namespaces) ~ O(pods)) this can grow very quickly (we have a 10k namespace cluster which has 3 service accounts per namespace and 3 secrets per namespace).union(permissions_of_any_service_account)
which is often cluster adminFuture direction:
type
field of a secret defines a schema of the data fields - it's not difficult to imagine that additional metadata might be added to the secret to identify where it residestoken
andca.crt
in a directory doesn't necessarily care how Kube provides that (it's a detail of the platform). Other secrets, like a service identity certificate, a pod client certificate, or a standard kerberos keytab, could be modeled as external volumes - but the semantics of how those are managed on the host is "as a secret".Goals:
PodPresets
able to use those dynamic secretsPossible changes:
ca.crt
in every secret for the master in etcdSecretDataSource
) and then delegate out to the remote entityAssumption of most external dynamic secret generators is that they need to be able to tie the requesting entity (node or pod) to a permission or fact (node A runs pod B under service account C) in order to release the secret.
The text was updated successfully, but these errors were encountered: