This is a Cluster Administrator guide to service accounts. It assumes knowledge of the User Guide to Service Accounts.
Support for authorization and user accounts is planned but incomplete. Sometimes incomplete features are referred to in order to better describe service accounts.
Kubernetes distinguishes between the concept of a user account and a service account for a number of reasons:
Three separate components cooperate to implement the automation around service accounts:
The modification of pods is implemented via a plugin called an Admission Controller. It is part of the apiserver. It acts synchronously to modify pods as they are created or updated. When this plugin is active (and it is by default on most distributions), then it does the following when a pod is created or modified:
ServiceAccount
set, it sets the ServiceAccount
to default
.ServiceAccount
referenced by the pod exists, and otherwise rejects it.ImagePullSecrets
, then ImagePullSecrets
of the ServiceAccount
are added to the pod.volume
to the pod which contains a token for API access.volumeSource
to each container of the pod mounted at /var/run/secrets/kubernetes.io/serviceaccount
.Starting from v1.13, you can migrate a service account volume to a projected volume when
the BoundServiceAccountTokenVolume
feature gate is enabled.
The service account token will expire after 1 hour or the pod is deleted. See more details about projected volume.
TokenController runs as part of controller-manager. It acts asynchronously. It:
You must pass a service account private key file to the token controller in the controller-manager by using
the --service-account-private-key-file
option. The private key will be used to sign generated service account tokens.
Similarly, you must pass the corresponding public key to the kube-apiserver using the --service-account-key-file
option. The public key will be used to verify the tokens during authentication.
A controller loop ensures a secret with an API token exists for each service
account. To create additional API tokens for a service account, create a secret
of type ServiceAccountToken
with an annotation referencing the service
account, and the controller will update it with a generated token:
secret.json:
{
"kind": "Secret",
"apiVersion": "v1",
"metadata": {
"name": "mysecretname",
"annotations": {
"kubernetes.io/service-account.name": "myserviceaccount"
}
},
"type": "kubernetes.io/service-account-token"
}
kubectl create -f ./secret.json
kubectl describe secret mysecretname
kubectl delete secret mysecretname
Service Account Controller manages ServiceAccount inside namespaces, and ensures a ServiceAccount named “default” exists in every active namespace.
Was this page helpful?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.