In the context of Kubernetes Cluster Architecture, ServiceAccounts serve as the identity system for processes (Pods) running inside the cluster, distinct from User accounts which are intended for humans. While Users are global, ServiceAccounts are namespaced resources. By default, every namespace cā¦In the context of Kubernetes Cluster Architecture, ServiceAccounts serve as the identity system for processes (Pods) running inside the cluster, distinct from User accounts which are intended for humans. While Users are global, ServiceAccounts are namespaced resources. By default, every namespace contains a 'default' ServiceAccount, which is automatically mounted into Pods to facilitate communication with the API server, unless the 'automountServiceAccountToken' field in the Pod specification is explicitly set to false.
Token management has undergone significant changes relevant to the CKA exam. Historically, creating a ServiceAccount automatically generated a Secret containing a long-lived JSON Web Token (JWT). However, in modern Kubernetes versions (v1.24+), this automatic Secret generation was removed to enhance security. The cluster now relies on Bound Service Account Tokens via the TokenRequest API. These modern tokens are projected into Pods as volumes; they are time-limited, audience-bound, and rotate automatically, ensuring that stolen credentials have a limited lifespan.
If you require a token for external use (such as a CI/CD pipeline accessing the cluster), you must now explicitly request a short-lived token using the command 'kubectl create token <service-account-name>'. If a legacy long-lived token is strictly necessary, you must manually create a Secret object with the annotation 'kubernetes.io/service-account.name'. For the CKA, mastering how to create these accounts, manage their associated RBAC RoleBindings, and handle token creation via the command line is essential for securing cluster configuration.
Mastering ServiceAccounts and Tokens for CKA
Why is it Important? In a Kubernetes cluster, security is paramount. While human users differ from cluster to cluster (often managed externally via OIDC or certificates), processes running inside Pods need a standardized, internal way to authenticate with the API Server. ServiceAccounts (SAs) provide this identity. Understanding SAs is critical because they form the basis of Role-Based Access Control (RBAC) for your applications. If a Pod needs to view endpoints, list nodes, or update secrets, it does so using the identity and credentials of its ServiceAccount.
What is it? A ServiceAccount is a namespaced Kubernetes resource. Unlike User Accounts, ServiceAccounts are managed by the Kubernetes API. 1. Identity: It acts as the 'ID card' for a process. 2. Scope: It is bound to a specific namespace. 3. Default: Every namespace has a ServiceAccount named default which is assigned to Pods if no other SA is specified.
How it Works The mechanism relies on ServiceAccount Tokens (JWTs). Legacy vs. Modern (Important for Exam): Prior to Kubernetes v1.24, creating an SA automatically created a Secret containing a permanent token. In modern versions (relevant to the current CKA), this no longer happens automatically. Instead, Kubernetes uses the TokenRequest API. 1. When a Pod starts, the Kubelet requests a short-lived token from the API server. 2. This token is mounted into the Pod as a projected volume at /var/run/secrets/kubernetes.io/serviceaccount. 3. The application reads this file to authenticate API requests.
Exam Tips: Answering Questions on ServiceAccounts and token management 1. Creating ServiceAccounts: Always use imperative commands to save time. kubectl create serviceaccount my-sa
2. Assigning SAs to Pods (The 'Immutable' Trap): A common exam task is to configure a Pod to use a specific ServiceAccount. The field in the Pod YAML is serviceAccountName. Crucial Tip: You cannot update the serviceAccountName of an already running Pod. If the question asks you to change the SA for an existing Pod, you must delete the Pod and recreate it (or use kubectl replace --force on the modified YAML).
3. Handling Tokens: If a question asks you to generate a token for an external app to act as a ServiceAccount, do not look for a Secret. Use the command: kubectl create token my-sa You can verify the token payload using jwt.io (if allowed/available) or simply trust the output.
4. Security Hardening (Automount): You may be asked to secure a Pod that does not require API access. To do this, disable the token mounting mechanism to reduce the attack surface. Set automountServiceAccountToken: false in the Pod spec or the ServiceAccount definition.
5. Troubleshooting Permissions: If a Pod cannot access resources, check two things: First, is it using the correct ServiceAccount? Second, does that ServiceAccount have a RoleBinding or ClusterRoleBinding granting the necessary permissions? A ServiceAccount without a RoleBinding has no permissions beyond unauthenticated users.