Security
Security
This domain tests cluster access control and workload isolation: authentication, RBAC authorization, service accounts, Pod Security Admission, NetworkPolicies, and Secret handling. Expect scenario questions about who can do what and why a Pod is rejected.
Authentication and RBAC
Users authenticate via certificates, tokens, or OIDC; workloads authenticate with ServiceAccounts. RBAC is additive: Roles grant verbs on resources within a namespace; ClusterRoles grant cluster-scoped resources or namespaced resources cluster-wide when bound. Bind with RoleBinding or ClusterRoleBinding. kubectl auth can-i checks effective permissions. The API server authorizes after authentication and admission.
Workload security
Pod Security Admission enforces privileged, baseline, or restricted profiles per namespace via labels. SecurityContexts set runAsNonRoot, readOnlyRootFilesystem, capabilities, and seccomp. NetworkPolicies are namespaced and select Pods; they require a CNI that enforces them. A default-deny ingress policy isolates selected Pods, but egress needs its own policy.
Worked example
A Pod using ServiceAccount reporter gets 403 listing Pods. kubectl auth can-i list pods --as=system:serviceaccount:dev:reporter returns no. Create a Role in dev allowing list on pods, then a RoleBinding to the SA. Test again. A ClusterRoleBinding would grant cluster-wide access, which is broader than needed. RBAC evaluates the verb and resource plus the binding scope; a RoleBinding to a ClusterRole only grants the ClusterRole's rules within the namespace.
Traps
RoleBindings do not grant cluster-scoped resources. The default ServiceAccount token is automounted unless disabled. NetworkPolicies are additive allow rules; no policy means allow all. Secrets in environment variables are visible in process listings.