Kubernetes Security Essentials: CNPA practice questions

Kubernetes security for a platform team is mostly about safe defaults applied consistently, so that every namespace a team receives starts out locked down. The essentials fall into a handful of areas, each with a built-in mechanism.

Access to the API comes first. Every request is authenticated and then authorized, usually by RBAC. The RBAC API declares four kinds of object: Role and ClusterRole hold sets of permissions, and RoleBinding and ClusterRoleBinding grant them to users, groups or service accounts. Roles and RoleBindings are namespaced, while the cluster variants apply across the cluster. Permissions are purely additive and there are no deny rules, so least privilege means granting only what is needed rather than taking rights away later. Workloads authenticate with service accounts. Current clusters give Pods short-lived, automatically rotating tokens obtained through the TokenRequest API, and a Pod that does not need the API can set automountServiceAccountToken to false.

Workload hardening is defined by the Pod Security Standards. Privileged is unrestricted and meant for trusted system and infrastructure workloads. Baseline is minimally restrictive, prevents known privilege escalations and allows the default Pod configuration. Restricted follows current Pod hardening best practices, for example requiring containers to run as non-root and to drop all capabilities. The built-in Pod Security admission controller applies a level per namespace, and the Kubernetes security checklist asks that an appropriate level be applied and enforced for all namespaces. Pod Security admission replaced PodSecurityPolicy, which has been removed.

Network access is controlled with NetworkPolicies; a platform commonly gives each namespace a default-deny posture and opens required flows deliberately. Secrets need care. By default they are stored unencrypted in etcd, the values in manifests are only base64 encoded, and anyone with API access to read Secrets, or access to etcd, can retrieve them. The documentation recommends enabling encryption at rest and configuring least-privilege access to Secrets.

The cluster's own configuration and supply chain matter too. The checklist covers keeping the API server, kubelet API and etcd off the public internet, limiting access to etcd, and enabling seccomp and AppArmor or SELinux on nodes that support them. For images, a digest is an immutable hash of the content, while a tag can be moved to point at a different image.

For a platform, these controls become part of the golden path. New namespaces arrive with RBAC bindings for the owning team, a Pod Security level, default network policies and resource quotas, and policy engines enforce whatever the built-ins do not cover.

Misconceptions include believing base64 is encryption, that a namespace isolates workloads without further controls, that RBAC can deny a specific action, and that PodSecurityPolicy is still available.

At associate level, expect questions on the three Pod Security levels, how the RBAC objects fit together, why secrets need encryption at rest and tight access, and which control addresses a given risk.