TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

👋 👋 A big thank you to today's sponsor SUPERHUMAN AI

ChatGPT is insanely powerful.

But most people waste 90% of its potential by using it like Google.

These 1,000+ proven ChatGPT prompts fix that and help you work 10X faster.

Sign up for Superhuman AI and get:

Claim your free prompts

Powered by: Jobsurface.com

Browse 582 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 55,000+ Cloud Native Professionals? Let's work together. Advertise With Us

Kubernetes looks simple from the outside. You write a YAML file, run kubectl apply, and your application is running in a cluster. But underneath that single command is one of the most carefully designed request processing pipelines in distributed systems engineering.

Before a single pod is scheduled, before a container image is pulled, before etcd stores a single byte of cluster state, your request passes through a security and validation gauntlet that most engineers never think about until something rejects their deployment and they have no idea why.

Understanding this pipeline is the difference between a cluster that enforces security policies consistently and one that relies on human discipline to stay compliant.

To understand admission control, you first need a clear mental model of what the Kubernetes API server is and who sends it requests.

There are two categories of traffic hitting a Kubernetes cluster. The first is operator traffic: admins, developers, and CI/CD systems communicating through kubectl or direct API calls. The second is user traffic: browsers and applications reaching workloads running on the nodes.

These two paths are completely separate. User traffic goes through the node's kube-proxy to the running pods. Operator traffic goes through the firewall boundary and hits the API server in the control plane.

The control plane contains the components that decide what runs in the cluster. The API server is the central hub: every change to cluster state flows through it. The Scheduler decides which node gets which pod. The Controller Manager runs the reconciliation loops that keep the actual state matching the desired state. etcd is the distributed key-value store that holds all cluster state. Nothing is written to etcd without passing through the API server first, which is exactly what makes the API server the right place to enforce security and policy.

The worker nodes run the actual workloads. kubelet is the node-level agent that receives pod specifications from the API server and tells the container runtime to pull images and start containers. kube-proxy maintains the network rules that route traffic to pods. Neither of these components has any involvement in whether a request is allowed through. That decision is made entirely in the API server pipeline.

Every request that reaches the Kubernetes API server, whether it is creating a pod, updating a ConfigMap, or deleting a namespace, passes through the same three-stage pipeline before it is persisted to etcd.

Authentication answers the question "who are you?" The API server accepts several credential types: X.509 client certificates, bearer tokens, service account tokens, and OIDC tokens from external identity providers. If none of these produces a valid identity, the request is rejected with a 401. The API server does not have a user database; it delegates identity verification to the configured authenticator plugins and accepts the first one that succeeds.

Authorization answers the question "can you do this?" Once you have an authenticated identity, the API server checks whether that identity is permitted to perform the requested action on the requested resource. The dominant model is RBAC: Role-Based Access Control. A Role defines a set of permissions (get pods in namespace X, create deployments, delete secrets). A RoleBinding attaches that role to a user, group, or service account. If no policy grants the requested permission, the request is rejected with a 403.

This is where most engineers stop thinking about security. Authentication and authorization look like the complete story. But they are not.

Admission control is the third gate, and it is the one that gives Kubernetes operators genuine cluster-wide governance. An authenticated, authorized request has established who you are and that you have permission to create this resource. Admission control answers the deeper question: should this specific resource, with these specific properties, be allowed into the cluster at all?

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)