Introduction

Hello folks! In this one we’re going all in on authorization and authentication in Kubernetes. Whenever you get access to a Kubernetes cluster in your job do you ever wonder what happens behinds the scenes? The DevOps guy just sends you a kubeconfig yaml file and you start using it. We’ll be going through the basics of Authentication and Authorization in Kubernetes covering 3 main parts:

1. Kubernetes Authentication Workflow

2. Authentication Methods in Kubernetes

3. User vs. Pod Authentication

Authentication Workflow

The Kubernetes authentication workflow serves as the first line of defense, verifying "who" is making the request to the Kubernetes API server which is the main entry point for all Kubernetes operations. Every request to the cluster, whether it’s from a kubectl command, a CI/CD pipeline, or an application, must pass through the API server.

Any request that comes in passes by the first phase which is Identity Assertion. Usually the request would carry any of the following:

• Client Certificates: TLS certificates that the API server can validate.

• Bearer Tokens: Passed in the Authorization header of the HTTP request.

• Custom Mechanisms: OpenID Connect (OIDC) (AWS IAM) , etc .

Kubernetes supports a pluggable authentication mechanism. The API server evaluates the configured authentication plugins in the following order:

• Static Token File.

• Client Certificate Authentication.

• Webhook Token Authentication.

• OpenID Connect (OIDC).

• HTTP Proxy Authentication.

If a plugin authenticates the request, the process stops, and the identity is assigned to the request and it moves to the Authorization phase of the request. Otherwise it returns a 401 Unauthorized.

Once authentication confirms the identity, the request moves to the authorization phase. In this phase:

• Kubernetes evaluates whether the authenticated user has permission to perform the requested action on the specified resource.

• Authorization mechanisms include for example Role-Based Access Control (RBAC)

Once authorized the request is then being processed and returned to the caller.

Authentication Methods in Kubernetes

As mentioned above there exist different authentication methods in Kubernetes, these methods cater to both user (human) and machine authentication. Here’s an overview of the main methods:

• Static Token File where tokens are stored in a static file provided by the Kubernetes API server. These tokens never change until changed manually. Not ideal for production environments as the token could get stolen by an attacker and used for malicious intentions.

• Service Account Tokens where tokens are automatically generated and mounted inside pods, stored in Kubernetes Secrets. These tokens are used with Kubernetes Service Accounts which are tied to specific permissions, Ideal for pod-to-API server communication, especially for applications running inside the cluster. Before Kubernetes 1.21 they used to be static but after they are renewable and bound to stricter audiences and permissions.

• Client Certificate Authentication uses TLS certificates to verify identities, ensuring that only trusted entities can access the Kubernetes API server. Can be used to authenticate humans alone or with service accounts together. A certificate authority generates and signs a user’s certificate and validates against it.

• Custom mechanisms include OpenID Connect where Kubernetes asks an external OID provider for authentication instead of using its native one.

User vs Pod Authentication

Kubernetes provides distinct mechanisms to authenticate users (human operators or external tools) and pods (workloads running within the cluster).

User Authentication

User authentication refers to how human users or external tools (e.g., CI/CD pipelines) authenticate with the Kubernetes API server to perform actions like managing resources. Methods include:

1. Certificate Authentication

2. Static Tokens (Not recommended)

3. OpenID Connect (OIDC)

Kubernetes doesn’t manage users directly; external systems (e.g., certificates, identity providers) are required.

Pod Authentication

Pod authentication refers to how workloads running inside the cluster (e.g., pods) authenticate with the Kubernetes API server to perform actions like reading secrets or interacting with resources.

The main way to do this is by service accounts, where each pod is automatically assigned a service account and the tokens get mounted into the pod.

These tokens are used by applications within the pod to authenticate with the API server.

The benefits of this is that its namespace scoped and really controlled.

Summary

There you have it! a brief introduction about authentication and authorization in Kubernetes, I think as a Backend Developer its important to understand these concepts and appreciate how dynamic and flexible Kubernetes made it. The designs can carry on to your day to day work.

What’s Next?

I’ll be doing a demo where image someone new joined the company and needs minimal access to the cluster. I’ll be walking through the basic steps to do so. See you there!