Zero trust in Kubernetes — never trust, always verify

Zero trust is the discipline of not trusting any actor, network, or device by default — verifying identity, intent, and posture on every interaction. In Kubernetes, the principles translate into five concrete obligations: identity for every actor, authentication for every request, authorisation for every verb, encryption for every channel, and continuous posture. This lesson walks each principle and the failure modes of zero-trust theatre.

The five principles

NIST SP 800-207 (the canonical zero-trust reference) distils the model into five obligations. In Kubernetes:

flowchart TB
    P1[1. Identity for every actor] --> P2[2. Authentication for every request]
    P2 --> P3[3. Authorisation for every verb]
    P3 --> P4[4. Encryption for every channel]
    P4 --> P5[5. Continuous posture]

Each principle maps to controls in the cluster. A defensible zero-trust implementation addresses all five.

Principle 1: identity for every actor

Every actor — human, workload, node — has an identity. No anonymous interactions.

• Humans — OIDC to the API server. No static passwords, no shared service accounts, no client certificates with years-long expiry. The identity is the corporate IdP record.
• Workloads — ServiceAccount tokens, projected by the kubelet, scoped by audience. The identity is the SA name + the namespace + the audience.
• Nodes — kubelet client certificates, rotated by --rotate-server-certificates=true. The identity is the node name + the system:nodes group.

# Verify no anonymous access
kubectl auth whoami
# system:anonymous
# Should return an error (not the username)

Principle 2: authentication for every request

Every request to the API server, every request to the kubelet, every request from a workload to a peer — authenticated.

• API server — TokenReview authentication in the --authentication-config file. The chain tries each authenticator; the first match wins; an unmatched request is rejected.
• Kubelet — Webhook authentication back to the API server. No local bypass.
• Pod-to-Pod — mTLS via a service mesh (Istio, Linkerd, Cilium). No plaintext.
• Pod-to-API — projected SA token in the Pod’s filesystem, scoped by audience.

Principle 3: authorisation for every verb

Every authenticated request is authorised. No implicit allow.

• API server — RBAC at the API level (Role/ClusterRole + bindings). Node authorization for kubelet requests. Webhook authorization for custom policy.
• Kubelet — Webhook authorization, not AlwaysAllow.
• Pod-to-Pod — AuthorizationPolicy in a service mesh, or NetworkPolicy at L3/L4 (which is weaker but the only built-in option).
• Filesystem — Pod Security Standards enforce runAsNonRoot and the allowed volume types, which rules out hostPath. readOnlyRootFilesystem is worth setting too, but no PSS profile checks it — enforce that one with a policy engine.

Principle 4: encryption for every channel

Every communication is encrypted. No plaintext.

• API server ↔ etcd — TLS with cert auth. The flag is --etcd-certfile, --etcd-keyfile, --etcd-cafile.
• API server ↔ kubelet — TLS via the kubelet’s serving certificate.
• Kubelet ↔ runtime — Unix socket, local-only.
• Pod ↔ Pod — mTLS in a service mesh; or assume in-cluster network is untrusted and use NetworkPolicy
  • application-layer TLS (e.g., HTTPS, gRPC TLS).
• etcd data at rest — EncryptionConfiguration with a KMS provider. The flag is --encryption-provider-config.
• API server audit log — TLS to the webhook destination.

# Verify API server ↔ etcd encryption
kubectl get pods -n kube-system -l component=etcd -o yaml | grep etcd-certfile
# Should show a mounted certificate file

Principle 5: continuous posture

The cluster’s posture is monitored continuously, not asserted once. Drift is detected and alerted.

• CIS Benchmark — kube-bench as a CronJob, results exported to the SIEM.
• Workload config — polaris as a validating webhook, blocking deployments that violate PSS.
• Image provenance — admission enforces signed images only; unsigned images are rejected.
• Runtime detection — Falco watches for syscall anomalies (shell in a container, outbound to a non-allow-listed IP, etc.).
• Audit log — every API request, every verb, every user. Alerted on indicators of compromise.

Zero-trust theatre

Five common failure modes:

1. Service mesh without mTLS to the API server. The mesh encrypts Pod-to-Pod, but the API server still accepts anonymous or weak auth. The strongest layer is left unhardened.
2. RBAC on the cluster, no admission. A workload can be deployed with privileged: true; RBAC has no view into the Pod spec. The cluster’s RBAC is perfect; the workload’s spec is dangerous.
3. Image signing without admission. The team ships Cosign and signs every image, but the admission controller is not configured to verify. The signing is documentation, not enforcement.
4. Kubelet hardening without API server hardening. The kubelet is locked down; the API server has --anonymous-auth=true and --insecure-port=8080 (legacy chart default). The cluster is half-hardened.
5. Continuous posture, no remediation. The team runs kube-bench weekly and reports the score, but FAILs do not become tickets. The posture programme is measurement without action.

Production failure modes

1. Zero trust is treated as a product, not a discipline. A team that buys a service mesh and declares victory has not addressed four of the five principles.
2. Zero trust is over-applied to the wrong actor. A workload that calls the cluster API to fetch a ConfigMap is not a security risk if it has a scoped SA and PSS restricted. Over-applying zero trust to every internal request adds latency and operational burden without security value.
3. Zero trust is rolled out without an audit log. If the audit log is missing or under-sampled, the team cannot verify that the controls work. Zero trust without audit is unfalsifiable.

Cross-course references

• The Linux course covers the kernel primitives (capabilities, seccomp, namespaces) that underpin zero trust at the workload layer.
• The Observability course covers the audit log that makes zero trust falsifiable.
• The OPNsense course covers the network zero-trust controls that the cluster sits behind.

Quiz

Production discipline

Zero trust in Kubernetes is a discipline of all five principles, addressed at every layer, continuously verified by the audit log. The service mesh is one control of one principle at one layer. A defensible programme ships controls for every cell of the principle × layer matrix, measures each one with kube-bench / polaris / Falco, and reports the trend to the security weekly meeting. The audit log is the falsification mechanism: a zero-trust claim that is not visible in the audit log is not implemented. Real zero trust is auditable; theatre is not.