Kubernetes Notes

Appearance

How does Kubernetes implement security at multiple layers (RBAC, namespaces, network policies, Pod security)?

Lets break down the multi-layered security architecture of Kubernetes.

Securing a Kubernetes cluster requires a "Defense in Depth" approach. Because Kubernetes is entirely API-driven, security is primarily implemented by placing gates and policies around the API server (Control Plane) and constraining the runtime environment of the Pods (Data Plane).

Here is how these layers function and interact to secure the platform.

1. Control Plane Security: Authentication & RBAC ​

The first line of defense is controlling who can access the API server and what they can do once authenticated.

  • Authentication (AuthN): This verifies identity. Kubernetes does not have an internal database of users; it relies on external sources (like OIDC, client certificates, or bearer tokens) to validate credentials. It distinguishes between human users and ServiceAccounts (identities for processes running in Pods).
  • Authorization (AuthZ) via RBAC: Once authenticated, every API request is checked against policies. Role-Based Access Control (RBAC) is the standard method for regulating access.
    • Roles vs. ClusterRoles: A Role defines permissions (like "list pods") within a specific Namespace, while a ClusterRole defines permissions cluster-wide (or for non-namespaced resources like Nodes).
    • Bindings: Permissions are additive and granted by binding a Role to a "Subject" (User, Group, or ServiceAccount) via a RoleBinding or ClusterRoleBinding.
    • Best Practice: Adhere to the principle of least privilege. Avoid using wildcards (*) in Rules, as this grants access to current and future API objects, potentially leading to privilege escalation.

2. Logical Isolation: Namespaces ​

Namespaces provide a scope for names and a mechanism to attach authorization and policy to a subsection of the cluster.

  • Partitioning: They allow you to divide cluster resources between multiple users or teams (multi-tenancy).
  • Scoping Policy: Security controls like RBAC Roles, NetworkPolicies, and ResourceQuotas are scoped to Namespaces.
  • Engineering Reality: A Namespace acts as a "soft" boundary. By itself, it does not prevent network traffic or resource exhaustion between tenants. You must explicitly apply NetworkPolicies and Quotas to a Namespace to make it a secure boundary.

3. Network Security: NetworkPolicies ​

By default, Kubernetes networking is "flat" and permissive: any Pod can communicate with any other Pod in the cluster, regardless of which Namespace or Node they are on.

  • The Mechanism: A NetworkPolicy is a declarative API object that acts as a firewall for Pods (Layer 3/4). It restricts traffic based on labels, IP blocks, and ports.
  • Enforcement: The policy is defined in the API, but it is enforced by the CNI Plugin (Container Network Interface). If your CNI (like Calico, Cilium, or Antrea) does not support NetworkPolicies, creating the object will have no effect.
  • Isolation Types: You can define specific Allow-lists for Ingress (incoming) and Egress (outgoing) traffic.
  • Best Practice: A "Default Deny" policy is recommended for multi-tenant namespaces. This blocks all traffic by default, forcing developers to explicitly allow listing only necessary connections.

4. Workload Security: Pod Security & Contexts ​

This layer controls the privileges of the containers running on the nodes to prevent them from attacking the host OS or other containers.

Pod Security Standards (Admission Control) ​

Kubernetes enforces security standards at the time of Pod creation using the built-in Pod Security Admission (PSA) controller. This replaces the deprecated PodSecurityPolicy (PSP). PSA defines three distinct profiles applied via Namespace labels:

  1. Privileged: Unrestricted (e.g., for system agents requesting direct hardware access).
  2. Baseline: Minimally restrictive, preventing known privilege escalations (default for common applications).
  3. Restricted: Heavily restricted, following hardening best practices (requires dropping capabilities, running as non-root, etc.).

Security Contexts (Runtime Configuration) ​

While PSA enforces standards at the cluster level, the securityContext field in the Pod specification defines the actual runtime privileges.

  • User ID: Using runAsUser and runAsNonRoot to prevent processes from running as root (UID 0).
  • Capabilities: Using capabilities to add or drop Linux kernel capabilities (e.g., dropping ALL capabilities and adding back only NET_BIND_SERVICE).
  • Filesystem: Using readOnlyRootFilesystem to prevent attackers from writing to the container's file system.
  • Kernel Hardening: Configuring seccompProfile (to filter syscalls) and appArmorProfile (to restrict program access) provides deep defense against container breakouts.

5. Data Security: Secrets & Encryption ​

  • Secrets: Sensitive data (passwords, keys) should be stored in Secret objects rather than ConfigMaps. However, by default, Secrets are base64-encoded (not encrypted) in the API.
  • Encryption at Rest: To protect sensitive data stored in etcd, you must enable Encryption at Rest using an EncryptionConfiguration.
  • KMS Integration: For production security, use the KMS (Key Management Service) provider. This uses envelope encryption, where a local data encryption key (DEK) is encrypted by a key encryption key (KEK) managed by an external KMS (like AWS KMS or Google Cloud KMS), ensuring the master keys never live on the cluster's disk.