Study notes · 10% of the exam

RBAC, Pod Security and Network Policy

Kubernetes security layers authentication, RBAC authorization and admission control, then hardens Pods with securityContext and Pod Security Standards, isolates traffic with NetworkPolicies, and protects data and the supply chain.

Key points

1
Every request passes authentication, authorization (usually RBAC) and admission. RBAC is additive and has no deny rules.
2
A RoleBinding that references a ClusterRole grants it only in that namespace. Nodes and other cluster-scoped objects need a ClusterRoleBinding.
3
Permission to create Pods or workloads in a namespace means running as any ServiceAccount and mounting any Secret there. Treat it as sensitive.
4
Pod Security Admission applies the privileged, baseline and restricted profiles through namespace labels. enforce rejects Pods, while warn and audit only report.
5
NetworkPolicies isolate only the Pods they select, are additive allow-lists, and need a plugin that enforces them. Egress allow-lists must include DNS.
6
Secrets are stored unencrypted in etcd unless encryption at rest is configured, and the first provider in the EncryptionConfiguration encrypts writes.
7
Projected ServiceAccount tokens are short-lived and bound to the Pod. Disable automounting where the API isn't needed, and use workload identity for cloud access.

Common traps

list and watch on Secrets reveal their contents, not just their names.
In a NetworkPolicy from list, one element with both selectors means AND; two dash-separated elements mean OR.
system:masters bypasses RBAC entirely, so deleting bindings doesn't revoke a certificate in that group.

Read the source

Test yourself on RBAC, Pod Security and Network Policy

Ten questions, with the answer and explanation after each one.