Mastering Kubernetes Service Accounts: RBAC in Action

Service accounts exist to provide an identity for processes running in a Pod, distinguishing them from user accounts meant for human interaction. This separation is crucial for security and operational efficiency in Kubernetes environments. By leveraging service accounts, you can ensure that your applications have the necessary permissions to interact with the Kubernetes API without exposing user credentials.

ServiceAccount tokens can be bound to various API objects within the kube-apiserver, including Pods, Secrets, and Nodes. When a token is bound to an object, it carries additional claims in the JWT that identify the object it is associated with. For instance, if a token is bound to a Pod, it will include the Pod's metadata in its claims. This mechanism allows for fine-grained access control, ensuring that only the intended processes can interact with specific resources. You can create a token for a service account and bind it to a Pod using commands like kubectl create token my-sa --bound-object-kind="Pod" --bound-object-name="test-pod".

In production, be aware that while the TokenReview API can be used to verify the claims within a token, the API server does not persist TokenReview objects, which can lead to confusion. Additionally, the presence of both pod and node claims in a token indicates it is bound to a Pod, but the API server does not check for the existence of the referenced Node object. This means that if the Node is deleted, the token remains valid until it expires. Always use the TokenReview API to ensure the claims are still valid before relying on a token for access control. Keep in mind that the behavior of the aud and iss fields in the JWT can vary between clusters, which could impact your authentication logic.