In Kubernetes, the kube-apiserver acts as the gatekeeper for the cluster. Securing access involves two distinct, sequential stages: Authentication (AuthN) and Authorization (AuthZ).
**Authentication** addresses the question: "Who are you?" Since Kubernetes does not maintain a native database for s…In Kubernetes, the kube-apiserver acts as the gatekeeper for the cluster. Securing access involves two distinct, sequential stages: Authentication (AuthN) and Authorization (AuthZ).
**Authentication** addresses the question: "Who are you?" Since Kubernetes does not maintain a native database for standard users, it relies on external mechanisms. The API server validates credentials using enabled plugins. Common methods include X.509 Client Certificates (often embedded in kubeconfig files for administrators), Bearer Tokens (specifically ServiceAccount tokens for Pods), and external Identity Providers via OpenID Connect (OIDC). If the identity cannot be validated, the request fails with a 401 error.
**Authorization** addresses the question: "What can you do?" Once the user is identified, the API server checks if they have permission to perform the specific action (verb) on the specific resource. The primary mode for CKA candidates is **Role-Based Access Control (RBAC)**. In RBAC, permissions are defined in *Roles* (namespaced) or *ClusterRoles* (cluster-wide). These roles are then connected to subjects (Users, Groups, or ServiceAccounts) via *RoleBindings* or *ClusterRoleBindings*. Other authorization modes include Node (for Kubelets) and Webhook.
For the CKA exam, you must understand how to inspect the kube-apiserver static pod manifest (usually found in `/etc/kubernetes/manifests`) to verify flags like `--authorization-mode=Node,RBAC` and `--client-ca-file`. You are expected to be proficient in generating certificate signing requests (CSRs) for new users and creating RBAC policies to enforce the principle of least privilege.
Kubernetes API Server Authentication and Authorization
Why is it Important? The Kubernetes API Server (kube-apiserver) acts as the gateway to the cluster. It is the only component that interacts directly with the etcd database. Therefore, controlling access to it is the single most critical security aspect of cluster administration. Proper configuration ensures that only legitimate users and service accounts can access the cluster (Authentication) and that they can only perform actions they are explicitly allowed to do (Authorization).
What is it? It is the security mechanism that filters every HTTP request sent to the API server. It is not a single process but a pipeline of modules: 1. Authentication (AuthN): Answers the question 'Who are you?' 2. Authorization (AuthZ): Answers the question 'What are you allowed to do?'
How it Works When a request hits the API server, it flows through stages in a specific order:
1. Authentication: The API server creates an identity for the request. It does not look at the request body, only the headers and certificates. Common mechanisms include: - X509 Client Certs: Using client certificates signed by the cluster CA. - Bearer Tokens: Such as Service Account tokens (JWTs) or Bootstrap tokens. - Authentication Proxy: Offloading auth to an external provider (OIDC/LDAP). If authentication fails, a 401 Unauthorized is returned.
2. Authorization: Once the user is identified (e.g., 'User: jane', 'Group: devs'), the server checks if they have permission for the specific verb (get, list, create) on the specific resource (pods, services). Common modes include: - Node: A special mode for Kubelets. - RBAC (Role-Based Access Control): The standard method involving Roles, ClusterRoles, and Bindings. - Webhook: sending the request to an external service for approval. If authorization fails, a 403 Forbidden is returned.
Exam Tips: Answering Questions on API server authentication and authorization
1. Inspect the Manifest: Questions often require checking how the API server is configured. Always look at the static pod manifest located at /etc/kubernetes/manifests/kube-apiserver.yaml. Specifically, look for flags like: - --authorization-mode (e.g., Node,RBAC) - --client-ca-file (where valid client certs are verified)
2. The 'can-i' Command: This is your best friend for verifying permissions without manually reading through complex YAML files. You can impersonate a user to test their access: kubectl auth can-i create deployments --as=jane --namespace=dev
3. Managing Certificates (CSR): You may be asked to onboard a new user. This usually involves: - Generating a key and CSR (openssl). - Creating a CertificateSigningRequest object in Kubernetes. - Approving it: kubectl certificate approve <csr-name> - Extracting the signed certificate for the user.
4. RBAC Troubleshooting: If a scenario states 'User X cannot list pods', check: - Does the Role/ClusterRole have the 'list' verb for 'pods'? - Does the RoleBinding/ClusterRoleBinding link the correct User to that Role?
5. Service Accounts: Remember that pods use ServiceAccounts to talk to the API. If a specific Pod needs API access, you must create a ServiceAccount, bind it to a Role, and assign that ServiceAccount to the Pod spec.