Security Foundations

Kubernetes security isn’t something you can add as an afterthought—it needs to be designed into your cluster architecture from the beginning. The difference between a secure cluster and a vulnerable one often comes down to understanding the fundamental security model and implementing proper controls at every layer.

Kubernetes security operates on a principle of defense in depth, with multiple layers working together to protect your workloads. At its core, every request to the Kubernetes API server goes through three critical phases: authentication (who are you?), authorization (what can you do?), and admission control (should this action be allowed?).

Understanding the Security Model

The Kubernetes security model centers around the API server, which acts as the gateway for all cluster operations. Every kubectl command, every pod creation, and every service update flows through this central point. This centralization is actually a security advantage—it gives us a single place to implement and enforce security policies.

Authentication in Kubernetes can happen through several mechanisms. The most common approach for human users involves external identity providers like OIDC, while service accounts handle authentication for pods and automated systems. Let’s look at how service accounts work in practice:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: webapp-service-account
  namespace: production

This creates a service account that pods can use to authenticate with the API server. When you create a service account, Kubernetes automatically generates a token and mounts it into any pod that uses this account. The beauty of this system is that each workload can have its own identity with specific permissions.

Implementing Role-Based Access Control

RBAC is where Kubernetes security really shines. Instead of giving broad permissions, you can create fine-grained roles that follow the principle of least privilege. I’ve seen too many clusters where developers have cluster-admin rights “just to make things work”—that’s a security nightmare waiting to happen.

The RBAC model uses four key resources: Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings. Roles define what actions are allowed, while bindings connect those roles to users or service accounts. Here’s a practical example of a role for a development team:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: developer-role
rules:
- apiGroups: [""]
  resources: ["pods", "services", "configmaps"]
  verbs: ["get", "list", "create", "update", "delete"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list", "create", "update"]

This role allows developers to manage common resources in their namespace but prevents them from accessing cluster-wide resources or other namespaces. The key insight here is that permissions are additive—you start with nothing and explicitly grant what’s needed.

To connect this role to actual users, you create a RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: development
subjects:
- kind: User
  name: [email protected]
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

Cluster Hardening Fundamentals

Beyond RBAC, cluster hardening involves securing the underlying infrastructure and Kubernetes components. One of the first things I do on any new cluster is disable the default service account’s automatic token mounting. Most pods don’t need API access, so why give it to them?

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
  namespace: production
automountServiceAccountToken: false

API server configuration plays a crucial role in cluster security. Key settings include enabling audit logging, configuring proper TLS certificates, and setting up admission controllers. The admission controller system is particularly powerful—it can validate, mutate, or reject requests before they’re stored in etcd.

Network-level security starts with proper cluster networking configuration. Ensure your cluster nodes aren’t directly accessible from the internet, use private subnets where possible, and implement proper firewall rules. The API server should only be accessible from trusted networks or through a VPN.

Practical Security Verification

Once you’ve implemented these foundational security measures, you need to verify they’re working correctly. Testing RBAC permissions is straightforward with kubectl’s auth commands:

kubectl auth can-i create pods --as=[email protected] -n development
kubectl auth can-i delete nodes --as=[email protected]

These commands let you verify that users have the permissions they need and, more importantly, that they don’t have permissions they shouldn’t. I regularly audit permissions this way, especially after making changes to roles or bindings.

Security contexts provide another layer of protection by controlling how pods run. Even with proper RBAC, a compromised container could potentially escalate privileges or access sensitive host resources. Security contexts help prevent this by restricting what containers can do at runtime.

The foundation we’ve built here—proper authentication, RBAC, and basic hardening—creates the security baseline for everything else we’ll cover. In the next part, we’ll dive into network security and policies, building on these authentication and authorization controls to create network-level segmentation and traffic control. These foundational security measures aren’t just checkboxes to tick—they’re the building blocks that make advanced security patterns possible and effective.