Kubernetes Security Fundamentals

Kubernetes is an open-source system for running and managing containerised applications. A container is a lightweight, standalone package that contains everything needed to run a piece of software: code, runtime, system tools, and libraries. Think of a container as a single shipping container on a cargo ship. Kubernetes is the port that organises thousands of those containers so they can be loaded, unloaded, and moved efficiently.

Before containers, companies ran applications directly on servers. If one application crashed, it could take down the whole server. Containers isolate each application so that a crash in one does not affect the others. But with many containers spread across many servers, you need a way to control who and what interacts with each container. That control is the Kubernetes security model.

The security model has three main layers: authentication, authorisation, and admission control. Authentication means verifying who a user or machine is. The user might be a human administrator logging in with a password or a robot process running inside another application. Kubernetes does not store passwords itself. Instead, it trusts an external identity provider, such as Microsoft Entra ID or a certificate file. When you type a command like 'kubectl get pods', your tool sends a certificate or token to the Kubernetes API server. The API server checks that certificate against a trusted certificate authority. If it matches, you are authenticated.

Authorisation happens next. Even if the system knows who you are, you cannot do everything. Authorisation decides what actions you are allowed to perform. Kubernetes uses a system called RBAC, role-based access control. An RBAC policy is a set of rules that link a user (or a group of users) to a role. The role defines which API operations they can perform, such as 'create pods', 'delete services', or 'list secrets'. For example, a developer might have a role that allows them to view logs but not delete nodes. An administrator might have a role that allows them to create namespaces. RBAC is the most common authorisation method, and the CKS exam expects you to write and debug RBAC configuration files.

Admission control is the third layer. An admission controller is a piece of software that intercepts requests to the API server after authentication and authorisation have succeeded, but before the request is saved to the database. It can modify or reject the request. For instance, a built-in admission controller called 'NamespaceLifecycle' ensures that you cannot create a pod in a namespace that does not exist. Another called 'AlwaysPullImages' forces every pod to pull its container image from a registry, preventing a pod from using a stale local copy that might contain malware. The CKS exam frequently tests your ability to configure and enable admission controllers.

Beyond these three layers, there is network security. Kubernetes runs in a flat network by default, meaning any pod can talk to any other pod unless you restrict traffic. A network policy is a firewall rule that controls which pods can communicate. For example, you can create a network policy that allows only a frontend pod to talk to a database pod, blocking all other traffic. The CKS exam tests your ability to write network policies that enforce zero-trust principles: never trust, always verify.

Finally, there is secrets management. A secret in Kubernetes is an object that stores sensitive data such as passwords, OAuth tokens, and SSH keys. By default, secrets are stored unencrypted in the etcd database. Etcd is the key-value store that holds all cluster data. If an attacker gains access to etcd, they can read every secret. The CKS exam expects you to enable encryption at rest for secrets, rotate encryption keys regularly, and avoid storing secrets in environment variables whenever possible.

All of these components form the Kubernetes security model. The model is not a single product. It is a collection of integrated features that you must configure deliberately. If you leave defaults in place, your cluster is insecure. The CKS exam is designed to test whether you know how to harden each component.

For context, here is how the model replaces older approaches. Before Kubernetes, companies used virtual machines (VMs) and manual firewall rules. A VM is a pretend computer that runs on a physical server. Each VM had its own operating system, and administrators connected to it using a tool called SSH. To control access, you had to edit firewall rules on each VM individually. That was slow and error-prone. Kubernetes centralises all of that work in one API server, one RBAC system, and one set of admission controllers. You define security once and the system enforces it everywhere.

Understanding these fundamentals is critical because the CKS exam is a hands-on performance test. You will not answer multiple-choice questions. You will sit at a terminal and configure a live cluster. If you do not grasp authentication, authorisation, admission control, network policies, and secrets encryption, you will fail the exam tasks.

Imagine you work as a junior IT administrator for a company called QuickCart, an online grocery delivery service. QuickCart runs its entire platform on Kubernetes. They have a development cluster used by engineers to test new features, and a production cluster that serves real customers. You are tasked with securing the production cluster after a security audit revealed several vulnerabilities.

Your first task is to review and fix the RBAC configuration. An audit log shows that a former intern still has a role that can delete pods. You open the RBAC configuration file. You see a Role named 'pod-modifier' that is bound to multiple users via a RoleBinding. You need to remove the intern from that RoleBinding and create a new Role with restricted permissions for new employees. In the CKS exam, you would edit YAML files directly. In real life, you might use a command like:

'kubectl delete rolebinding intern-binding -n production'

Then you would create a new Role that only allows reading logs and restarting pods, not deleting them:

'kubectl create role readonly-logs --verb=get,list --resource=pods,logs'

'kubectl create rolebinding new-hire-binding --role=readonly-logs --user=alice@quickcart.com'

Your second task is to implement a network policy that isolates the payment processing pods. The audit found that a database pod in the same namespace is being accessed by a monitoring tool that should not have direct database access. You write a network policy that allows only the payment frontend pods to communicate with the backend payment database on TCP port 5432. All other traffic is denied. The policy uses podSelector to target the correct pods and ingress rules to whitelist specific sources.

Third, you discover that secrets are stored unencrypted in etcd. The company policy requires encryption at rest. You generate a new encryption key, create a YAML configuration file for the EncryptionConfiguration resource, and restart the kube-apiserver components. The CKS exam will simulate this exact scenario. You must know the structure of the EncryptionConfiguration file, including the providers block and the order of keys.

Fourth, you enable audit logging. You create an audit policy that logs all requests to the 'secrets' resource by any user who is not an admin. The logs are sent to a central logging system. In a real environment, this helps the security team detect data exfiltration attempts.

Finally, you run a kube-bench scan. Kube-bench is an open-source tool that checks your cluster against the CIS Kubernetes Benchmark, which is a set of security best practices published by the Center for Internet Security. The scan flags that the kubelet (the agent running on each worker node) is using a default port and has anonymous authentication enabled. You correct both issues by editing the kubelet configuration file and restarting the service.

Every one of these tasks appears on the CKS exam. The exam environment provides a cluster that is intentionally insecure. Your job is to identify and fix the vulnerabilities. You do not need to memorise every command. You need to understand the security concepts so well that you can apply them under time pressure.