Managing 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:

    • User accounts are intended to be global. Names must be unique across all namespaces of a cluster. Service accounts are namespaced.
    • Typically, a cluster’s user accounts might be synced from a corporate database, where new user account creation requires special privileges and is tied to complex business processes. Service account creation is intended to be more lightweight, allowing cluster users to create service accounts for specific tasks by following the principle of least privilege.
    • Auditing considerations for humans and service accounts may differ.
    • A config bundle for a complex system may include definition of various service accounts for components of that system. Because service accounts can be created without many constraints and have namespaced names, such config is portable.

    Service account automation

    Three separate components cooperate to implement the automation around service accounts:

    • A admission controller
    • A Token controller
    • A ServiceAccount controller
    1. If the pod does not have a ServiceAccount set, it sets the ServiceAccount to default.
    2. It adds a volume to the pod which contains a token for API access if neither the ServiceAccount automountServiceAccountToken nor the Pod’s is set to false.
    3. It adds a volumeSource to each container of the pod mounted at /var/run/secrets/kubernetes.io/serviceaccount, if the previous step has created a volume for ServiceAccount token.
    4. If the pod does not contain any imagePullSecrets, then imagePullSecrets of the ServiceAccount are added to the pod.

    Bound Service Account Token Volume

    FEATURE STATE: Kubernetes v1.22 [stable]

    The ServiceAccount admission controller will add the following projected volume instead of a Secret-based volume for the non-expiring service account token created by Token Controller.

    This projected volume consists of three sources:

    1. A ServiceAccountToken acquired from kube-apiserver via TokenRequest API. It will expire after 1 hour by default or when the pod is deleted. It is bound to the pod and has kube-apiserver as the audience.
    2. A ConfigMap containing a CA bundle used for verifying connections to the kube-apiserver. This feature depends on the feature gate, which publishes a “kube-root-ca.crt” ConfigMap to every namespace. RootCAConfigMap feature gate is graduated to GA in 1.21 and default to true. (This flag will be removed from —feature-gate arg in 1.22)
    3. A DownwardAPI that references the namespace of the pod.

    TokenController runs as part of kube-controller-manager. It acts asynchronously. It:

    • watches ServiceAccount creation and creates a corresponding ServiceAccount token Secret to allow API access.
    • watches ServiceAccount deletion and deletes all corresponding ServiceAccount token Secrets.
    • watches Secret deletion and removes a reference from the corresponding ServiceAccount if needed.

    You must pass a service account private key file to the token controller in the kube-controller-manager using the --service-account-private-key-file flag. The private key is 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 flag. The public key will be used to verify the tokens during authentication.

    To create additional API tokens

    A controller loop ensures a Secret with an API token exists for each ServiceAccount. To create additional API tokens for a ServiceAccount, create a Secret of type kubernetes.io/service-account-token with an annotation referencing the ServiceAccount, and the controller will update it with a generated token:

    To delete/invalidate a ServiceAccount token Secret

    A ServiceAccount controller manages the ServiceAccounts inside namespaces, and ensures a ServiceAccount named “default” exists in every active namespace.