CKA Notes: Kubernetes Authentication & Authorization

5 min readAug 3, 2023

The Kubernetes API server is the cluster’s brain and allows the users to perform various operations. Therefore, it is essential to secure access to the API server. There are two main mechanisms to control access:

Authentication — who can access the API server
Authorization — what actions can one perform on the API server

Authentication

There are two types of users in Kubernetes:

Users — human users
ServiceAccounts — machine users

Kubernetes does not support any in-built objects for user creation but supports the creation of ServiceAccount objects for service accounts. In order to authenticate users in Kubernetes we can follow the below mechanisms:

Static Password File (Deprecated in release 1.19)

Plain text file containing usernames and passwords. The file is used for validation at the time of the request
Passed to API-Server as a parameter in the manifest file — basic-auth-file=/path-to-file/userdetails.csv

2. Static Token File

Plain text file containing usernames and tokens. Used for validation at the time of the request
Currently, tokens last indefinitely, and the token list cannot be changed without restarting the API server
The token file is a CSV file with the following columns: token, user name, user uid, and group names (optional)

token,user,uid,"group1,group2,group3"

3. Certificates

Most common authentication choice in Kubernetes
X509 client certificates are used for authentication. If a client certificate is presented and verified, the common name of the subject is used as the user name for the request
Client certificate authentication is enabled by passing the --client-ca-file=FILEPATH option to the API server
Since Kubernetes 1.4, client certificates can also indicate a user’s group memberships using the certificate’s organization fields. To include multiple group memberships for a user, include multiple organization fields in the certificate. For example, the below will create a CSR for the username “john”, belonging to two groups, “app1” and “app2”

openssl req -new -key john.pem -out john-csr.pem \
-subj "/CN=john/O=app1/O=app2"

4. Identity Providers

In this approach, we integrate third-party identity providers such as LDAP, Kerberos, etc using OpenID Connect
Since all of the data needed to validate who you are is in the id_token, Kubernetes doesn't need to "phone home" to the identity provider

Authorization

Kubernetes authorization verifies every request to the API server to make sure the user can perform the requested operation. There are six types of authorization modes in Kubernetes:

Node Authorization
Attribute Based Access Control (ABAC)
Role Based Access Control (RBAC)
Webhook
Always Allow
Always Deny

To enable an authorization mode, we pass the mode(s) as a parameter to the API-server --authorization-mode=Node,RBAC. Kubernetes allows us to use multiple authorization modes. The authorization modes are accessed sequentially. If a request is denied by the first mode, it is sent to the next mode for approval. If all the modes reject the request, then the request is denied

Node Authorization

The Kubelet is the Kubernetes component that runs on each worker (and possible control plane) node and is responsible for managing the container runtime on the host. It communicates with the Kubernetes API server to get information about workloads that should be running on the node and then instantiates them using a container runtime like containerd
To perform its role, the kubelet needs access to the API Server. Node Authorization is a special kind of authorization mechanism that is only intended for the kubelet to access the API server. It cannot be used for user authorization
To be authorized by the Node authorizer, a kubelet must use a credential that identifies it as a member of the system:nodes group and has a specific username format of system:node:<nodeName> . Therefore, the kubelet sends its TLS certificate with the request to prove its identity

As per the node_authorizer code, here are the rules it follows 
while authorizing requests from kubelets:

1. If a Request is not from a node 
(NodeIdentity() returns isNode=false) -> reject
2. If a specific node cannot be identified 
(NodeIdentity() returns nodeName="") -> reject
3. If a request is for a secret, configmap, persistent volume, 
resource claim, or persistent volume claim, reject unless the verb is get, 
and the requested object is related to the requesting node: 
  node <- configmap
  node <- pod
  node <- pod <- secret 
  node <- pod <- configmap 
  node <- pod <- pvc 
  node <- pod <- pvc <- pv 
  node <- pod <- pvc <- pv <- secret
  node <- pod <- ResourceClaim
4. For other resources, authorize all nodes uniformly using 
statically defined rules

Attribute Based Access Control (ABAC)

Authorization mechanism where the access requests are evaluated based on the attributes of the request. In this mechanism, we create policy files that specify which users or groups are allowed to perform certain operations on specific Kubernetes API resources
This mechanism is not easily scalable and gets complicated as we add more users to the cluster. For each user/group, we have to update the policy file

apiVersion: abac.authorization.kubernetes.io/v1beta1
kind: Policy
spec:
  # Policy 1: Allow 'admin' user to perform all actions in any namespace.
  user: admin
  readonly: false

  # Policy 2: Allow 'developer' user to read pods in 'mynamespace' namespace.
  user: developer
  namespace: mynamespace
  resource: pods
  readonly: true

  # Policy 3: Allow 'group1' to read services and deployments in any namespace.
  group: group1
  resource: services
  readonly: true
  ---
  group: group1
  resource: deployments
  readonly: true

  # Policy 4: Deny access to all other users and groups (default deny).
  readonly: false

Role Based Access Control (RBAC)

RBAC is one of the most widely used authorization mechanisms where we create a set of roles(set of permissions) such as developer, tester, admin, etc., and then bind these roles to users/groups through role bindings
RBAC is much more simpler and scalable than ABAC as admins can easily edit roles or update bindings for new users

Webhook

Webhook authorization mode allows for custom authorization logic by delegating the authorization decision to an external HTTP service, known as a webhook
In this mode, when a request is sent to the API server, the server forwards the request to an externally configured authorization service, which computes the request and sends the decision back to the server
Allows us to have complex authorization logic via systems such as LDAP, custom auth service, etc.

AlwaysAllow & Always Deny

AlwaysAll allows all the requests, while AlwaysDeny denies all the requests
By default, a Kubernetes cluster has the AlwaysAllow mode enabled

REFERENCES:

CKA Notes: Kubernetes Authentication & Authorization

Authentication

Authorization

Written by Ambidextrous