Day 4 on Eriks training corner

Authentication and authorization

Mon, 01 Jan 0001 00:00:00 +0000

Authentication and authorization

Every request to the API server passes three gates.

Authentication

Kubernetes has no User objects. A user is whatever an authenticator says: a name and a list of groups.

RBAC and least privilege

Mon, 01 Jan 0001 00:00:00 +0000

RBAC and least privilege

graph LR S["Subject User / Group / ServiceAccount"] --> B[RoleBinding] B --> R["Role verbs on resources"] R -.valid in.-> NS[one namespace] S2[Subject] --> CB[ClusterRoleBinding] CB --> CR[ClusterRole] CR -.valid in.-> ALL[whole cluster]

Object	Scope	Contains
Role	namespace	rules
ClusterRole	cluster	rules (also for nodes, PVs, non-resource URLs)
RoleBinding	namespace	subjects -> Role or ClusterRole (limited to this namespace)
ClusterRoleBinding	cluster	subjects -> ClusterRole everywhere

Binding a ClusterRole with a RoleBinding is the common pattern: define “developer” once, grant it per namespace.

Service accounts

Mon, 01 Jan 0001 00:00:00 +0000

Service accounts

Identity for workloads. Every namespace has a default ServiceAccount and every Pod runs as one.

graph LR SA[ServiceAccount app] --> P[Pod serviceAccountName: app] K[kubelet] -->|projected token 1 h, bound to Pod| P P -->|Authorization: Bearer ...| API[API server] RB[RoleBinding] --> SA

The kubelet mounts a short-lived, audience-bound JWT into /var/run/secrets/kubernetes.io/serviceaccount/ (plus CA and namespace) and refreshes it. The token dies with the Pod. The API sees the Pod as system:serviceaccount:<ns>:<name>.

Security context and container hardening

Mon, 01 Jan 0001 00:00:00 +0000

Security context and container hardening

A container is a process on the node. The security context decides how much of the node that process can touch.

spec:
 securityContext: # Pod level - applies to all containers
 runAsNonRoot: true
 runAsUser: 10001
 fsGroup: 10001
 seccompProfile: { type: RuntimeDefault }
 containers:
 - name: app
 image: nginxinc/nginx-unprivileged:1.27  # listens on 8080
 securityContext: # container level - wins over Pod level
 allowPrivilegeEscalation: false
 readOnlyRootFilesystem: true
 capabilities:
 drop: ["ALL"]
 volumeMounts:
 - { name: tmp, mountPath: /tmp }  # writable scratch space
 volumes:
 - { name: tmp, emptyDir: {} }

Setting	Protects against
`runAsNonRoot` / `runAsUser`	root in the container = root-owned files on the node if it escapes
`allowPrivilegeEscalation: false`	setuid binaries, `sudo` inside
`readOnlyRootFilesystem: true`	attacker dropping tools or changing the app
`capabilities.drop: [ALL]`	raw sockets, changing ownership, binding ports < 1024
`seccompProfile: RuntimeDefault`	~300 rarely needed syscalls
never `privileged: true`, `hostPID`, `hostNetwork`, `hostPath: /`	these are the node

Container hardening checklist

Minimal base image (distroless, alpine, chiselled) - fewer CVEs, no shell.
Image built to run as non-root (USER 10001 in the Dockerfile).
Pinned tag or digest (@sha256:...), never latest.
Scanned in the pipeline (Trivy - Lab 33), signed (cosign).
Resource limits set (Day 3) - a runaway container cannot starve the node.
Only the ServiceAccount token it needs (usually none).

Many public images (nginx, httpd) expect root. Use their unprivileged variants or build your own.

Pod Security Standards and Admission

Mon, 01 Jan 0001 00:00:00 +0000

Pod Security Standards and Admission

Pod Security Standards define three levels. Pod Security Admission (built in) enforces them per namespace with labels.

Level	Allows	For
privileged	everything	system namespaces, CNI, storage drivers
baseline	no privileged, no host namespaces, no hostPath, no dangerous capabilities	most legacy apps
restricted	baseline + non-root, drop ALL, no privilege escalation, seccomp	new apps - the target

Mode	Effect
`enforce`	violating Pods are rejected
`audit`	allowed, recorded in the audit log
`warn`	allowed, the user sees a warning

apiVersion: v1
kind: Namespace
metadata:
 name: shop
 labels:
 pod-security.kubernetes.io/enforce: baseline
 pod-security.kubernetes.io/enforce-version: latest
 pod-security.kubernetes.io/warn: restricted
 pod-security.kubernetes.io/audit: restricted

The typical rollout: warn/audit restricted, enforce baseline - then fix the warnings and raise enforce.

Admission policies

Mon, 01 Jan 0001 00:00:00 +0000

Admission policies

PSA covers Pod security only. Organisation rules - “every Deployment has an owner label”, “images only from our registry”, “no latest” - need a policy engine in the admission chain.

graph LR R[request, authorized] --> M[mutating admission add defaults, sidecars] M --> S[schema validation] S --> V[validating admission PSA, VAP, Kyverno, Gatekeeper] V -->|allowed| E[(etcd)] V -->|denied| X[error to the user]

ValidatingAdmissionPolicy (built in)

Rules written in CEL, evaluated inside the API server - no extra component. GA since Kubernetes 1.30.

Network policies and segmentation

Mon, 01 Jan 0001 00:00:00 +0000

Network policies and segmentation

By default every Pod can talk to every Pod in every namespace. A compromised frontend can reach the database directly.

graph LR subgraph shop F[frontend] -->|allowed| B[backend] B -->|allowed| D[(db)] F -.x.-> D end O[other namespace] -.x.-> B

NetworkPolicy

Selects Pods and lists what may reach them (ingress) and what they may reach (egress). Enforced by the CNI - here Calico.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: db-from-backend, namespace: shop }
spec:
 podSelector:
 matchLabels: { app: db }  # the Pods this policy protects
 policyTypes: ["Ingress"]
 ingress:
 - from:
 - podSelector:
 matchLabels: { app: backend }
 ports:
 - { protocol: TCP, port: 5432 }

The rules of the game

A Pod selected by no policy: everything allowed.
A Pod selected by any policy for a direction: only what a policy allows.
Policies are additive - there is no “deny” rule, only “allow”.
from entries: podSelector, namespaceSelector, both combined (AND in one item, OR as separate items), ipBlock.
With egress policies, allow DNS (UDP/TCP 53 to kube-system) or nothing resolves.

# default deny in a namespace - start here
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny, namespace: shop }
spec:
 podSelector: {}
 policyTypes: ["Ingress", "Egress"]

Calico extras

The standard API is namespaced and allow-only. Calico adds (projectcalico.org/v3, visible to kubectl through the Calico API server):

Images, secrets and audit

Mon, 01 Jan 0001 00:00:00 +0000

Images, secrets and audit

Image scanning

graph LR C[code] --> B[build image] --> S["scan Trivy / Grype"] --> SIGN["sign cosign"] --> R[(registry)] R --> A["admission allowed registry? signed?"] --> K[cluster]

trivy image nginx:1.27 --severity HIGH,CRITICAL
trivy config ./manifests/ # misconfigurations in YAML, Helm, Dockerfile
trivy k8s --report summary # scan the running cluster

Fix order: base image update > fewer packages > accept with justification.

Warning

The scanner is part of your supply chain too. In March 2026 attackers published a malicious Trivy v0.69.4 and hijacked the trivy-action / setup-trivy GitHub Action tags to steal CI secrets. Pin tools and actions to verified versions or commit SHAs, and verify checksums and signatures.