SecuritySecurity

Part of the Kubernetes Roadmap knowledge base.

Overview

Kubernetes is powerful precisely because it is a single API that can create, destroy, and connect anything in your cluster — which is exactly why it is a high-value target. A compromised ServiceAccount token, an over-permissive RBAC binding, or a privileged Pod can escalate from one workload to the entire cluster and often into the underlying cloud account. Security is not a feature you switch on; it is a set of defaults you must change, because Kubernetes ships open by default: the Pod network is flat and default-allow, Secrets are only base64-encoded, and a Pod with the right permissions can mount the host filesystem.

A useful frame is the 4Cs of Cloud Native Security, a defense-in-depth model where each layer is secured within the one outside it:

• Cloud — the infrastructure: the cloud account, the control-plane endpoint, node OS hardening, IAM, network boundaries. The most privileged and foundational layer; a weakness here undermines everything above.
• Cluster — Kubernetes itself: authentication, RBAC, admission control, Pod Security, network policy, encrypting Secrets at rest, securing etcd and the API server.
• Container — the images and runtime: scanning for vulnerabilities, signing and verifying provenance, dropping capabilities, running as non-root.
• Code — your application: dependency management, input validation, TLS, secret handling. The innermost layer and the one you fully control.

You cannot secure an inner layer to compensate for a broken outer one — a perfectly hardened container on a cluster with cluster-admin bound to system:anonymous is still wide open. This page focuses on the Cluster and Container layers, where Kubernetes gives you the most direct controls: authentication (who are you), authorization (what may you do), admission control (should this specific request be allowed), and the runtime and supply-chain controls that constrain what workloads can do once running.

Fundamentals

The request lifecycle

Every call to the API server passes through three gates, in order. Understanding this pipeline explains where each control lives:

1. Authentication — establishes identity. If no authenticator recognizes the credential, the request is rejected as anonymous (or fails). Kubernetes has no user objects; identity comes from certificates, tokens, or an external provider.
2. Authorization — decides whether that identity may perform this verb on this resource. Almost always RBAC. Deny by default: if no rule grants access, it is denied.
3. Admission control — a chain of plugins and webhooks that can mutate (inject defaults, sidecars) and then validate (accept/reject) the object. This is where policy engines and Pod Security enforcement run, after authz has passed but before the object is persisted.

Authentication — who are you?

Kubernetes distinguishes two identity types:

• Normal users (humans) — managed outside Kubernetes. There is no User object. A user is whatever an authenticator vouches for:
  • X.509 client certificates — the CN becomes the username, the Organization fields become groups. Simple but hard to revoke (no built-in CRL) — avoid for humans at scale.
  • OIDC tokens — the recommended approach for humans. Kubernetes trusts an external identity provider (Okta, Entra ID, Google, Dex, Keycloak); users log in there and present a signed JWT. Groups and identity come from the token’s claims, so you manage people in your IdP and revoke centrally.
  • Authenticating proxy / cloud IAM (EKS aws-iam-authenticator / access entries, GKE/AKS IAM) — map cloud identities to Kubernetes users.
• ServiceAccounts (workloads) — first-class Kubernetes objects, namespaced, used by Pods to authenticate to the API. Each Pod gets a ServiceAccount (the namespace default SA if unspecified). Modern clusters issue short-lived, audience-bound projected tokens (via TokenRequest) automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token, replacing the old never-expiring Secret-based tokens.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-api
  namespace: prod
automountServiceAccountToken: false   # don't mount a token unless the Pod calls the API

Two important hardening moves: set automountServiceAccountToken: false on ServiceAccounts (or Pods) that never talk to the API server, and never grant permissions to the default ServiceAccount. In the cloud, bind a ServiceAccount to a cloud IAM role — IRSA / EKS Pod Identity (AWS), Workload Identity (GKE/AKS) — so Pods get scoped cloud credentials via their SA token instead of long-lived access keys.

Authorization — RBAC

Role-Based Access Control (RBAC) is the standard authorizer. It has exactly four object kinds, split by scope:

Two things trip people up. First, RBAC is purely additive and deny-by-default — there are no deny rules; you only grant, and anything not granted is forbidden. Second, a RoleBinding can reference a ClusterRole: this is the idiomatic way to reuse one permission set (say, “view”) across many namespaces without redefining it — the ClusterRole supplies the rules, the RoleBinding scopes them to its namespace.

A rule is apiGroups × resources × verbs. Verbs are get, list, watch, create, update, patch, delete, deletecollection. Wildcards (*) exist but are almost always a mistake outside genuine admin roles.

# A Role: read-only access to Pods and their logs in the "prod" namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: prod
  name: pod-reader
rules:
  - apiGroups: [""]                 # "" = core API group
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
---
# Bind that Role to a group (from OIDC claims) and a ServiceAccount
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: prod
  name: pod-reader-binding
subjects:
  - kind: Group
    name: "oncall-engineers"        # comes from the IdP token's groups claim
    apiGroup: rbac.authorization.k8s.io
  - kind: ServiceAccount
    name: log-collector
    namespace: prod
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Least privilege in practice: start from zero and grant only what a subject needs. Audit access with kubectl auth can-i --list --as=system:serviceaccount:prod:log-collector, and use tooling (rbac-lookup, kubectl-who-can, rakkess) to find over-grants. The cardinal sins are binding cluster-admin to a human or SA, using verbs: ["*"] on resources: ["*"], granting secrets broadly (readable Secrets = readable credentials), and permitting create on pods/pods/exec in a namespace with privileged ServiceAccounts (a lateral-movement path to token theft and escalation).

Key Concepts

Admission control

After authentication and authorization, the request hits the admission chain. Two phases run in sequence:

1. Mutating admission — webhooks and plugins can change the object: inject a sidecar (service mesh), add default labels, set a securityContext, apply a defaultRequest. Mutations run first so validation sees the final object.
2. Validating admission — webhooks and plugins accept or reject: enforce that images are signed, that no Pod is privileged, that resource limits are set. They cannot change the object, only pass judgment.

Built-in plugins (e.g. ResourceQuota, PodSecurity, LimitRanger) are compiled in. Beyond them, dynamic admission webhooks (MutatingWebhookConfiguration / ValidatingWebhookConfiguration) call out to your own HTTPS services, which is how policy engines plug in. A newer, in-process option is ValidatingAdmissionPolicy — validation rules written in CEL that run inside the API server without an external webhook, avoiding the availability and latency risk of a webhook that could block all writes if it goes down.

Pod Security Standards & Pod Security Admission

The Pod Security Standards (PSS) define three cumulative policy levels:

Pod Security Admission (PSA) is the built-in (GA since v1.25) admission controller that enforces these standards per namespace via labels. It replaced the deprecated PodSecurityPolicy. Each level can run in three modes independently: enforce (reject violating Pods), audit (allow but log), warn (allow but return a user-facing warning). A safe rollout is to first warn+audit at restricted, watch what breaks, then flip to enforce.

apiVersion: v1
kind: Namespace
metadata:
  name: prod
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: restricted        # warn on the same level for kubectl users
    pod-security.kubernetes.io/audit: restricted

PSA is coarse (three fixed levels, whole-namespace) — for finer, custom rules (“no :latest tag”, “images only from our registry”, “every Pod needs a team label”) you need a policy engine.

Policy engines — OPA Gatekeeper & Kyverno

Policy engines are validating (and mutating) admission webhooks that enforce arbitrary organizational rules, and can also audit existing resources for violations.

A Kyverno policy that requires the runAsNonRoot securityContext (validation via a declarative pattern):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-run-as-non-root
spec:
  validationFailureAction: Enforce      # Enforce = block; Audit = report only
  background: true
  rules:
    - name: check-run-as-non-root
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "Containers must set securityContext.runAsNonRoot=true."
        pattern:
          spec:
            containers:
              - securityContext:
                  runAsNonRoot: true

The equivalent Gatekeeper approach is a reusable ConstraintTemplate written in Rego plus a Constraint that applies it:

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequirenonroot
spec:
  crd:
    spec:
      names: { kind: K8sRequireNonRoot }
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequirenonroot
        violation[{"msg": msg}] {
          c := input.review.object.spec.containers[_]
          not c.securityContext.runAsNonRoot == true
          msg := sprintf("container %v must set runAsNonRoot=true", [c.name])
        }
---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequireNonRoot
metadata:
  name: require-non-root
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

securityContext — constraining the container

The securityContext is the per-Pod/per-container knob set that hardens the runtime. It is the concrete mechanism the restricted PSS level and the policy above check for. The gold-standard block:

spec:
  securityContext:                 # Pod-level
    runAsNonRoot: true             # refuse to start as UID 0
    runAsUser: 10001
    fsGroup: 10001                 # group ownership for mounted volumes
    seccompProfile:
      type: RuntimeDefault         # apply the runtime's default syscall filter
  containers:
    - name: app
      image: registry.example.com/app@sha256:abc123...   # pin by digest
      securityContext:             # container-level (overrides Pod-level)
        allowPrivilegeEscalation: false   # block setuid escalation (no gaining new privs)
        readOnlyRootFilesystem: true      # immutable container FS; write only to mounted volumes
        privileged: false
        capabilities:
          drop: ["ALL"]                   # drop every Linux capability...
          add: ["NET_BIND_SERVICE"]       # ...then add back only what's truly needed

What each control buys you:

• runAsNonRoot / runAsUser — a root process that escapes the container is root on the node; running as a non-zero UID contains the blast radius.
• allowPrivilegeEscalation: false — prevents a process from gaining more privileges than its parent (blocks setuid binaries), closing a common escalation route.
• readOnlyRootFilesystem: true — an attacker can’t drop tools or modify binaries in the container; mount emptyDir for the few paths that need to be writable.
• capabilities.drop: ["ALL"] — Linux capabilities are fine-grained root powers; drop them all and add back only the specific ones needed (e.g. NET_BIND_SERVICE to bind port <1024).
• seccompProfile: RuntimeDefault — restricts the syscalls the container can make to the container runtime’s vetted default set, shrinking the kernel attack surface.
• privileged: true — the opposite of all of the above; it grants near-host access. Treat it as a red flag reserved for a tiny set of system/infra DaemonSets.

NetworkPolicy — network isolation

By default every Pod can reach every other Pod across all namespaces — the network is flat and default-allow. A NetworkPolicy changes this to default-deny for selected Pods, then allow-lists specific traffic. NetworkPolicies are enforced by the CNI plugin (Calico, Cilium, etc.) — applying one on a CNI that doesn’t support them silently does nothing.

The foundational move is a default-deny policy per namespace, then explicit allows:

# 1) Deny all ingress + egress in the namespace (empty selector = all Pods)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: prod
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
---
# 2) Allow the api Pods to receive traffic only from the web Pods, on 8080
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-web-to-api
  namespace: prod
spec:
  podSelector:
    matchLabels: { app: api }
  policyTypes: ["Ingress"]
  ingress:
    - from:
        - podSelector:
            matchLabels: { app: web }
      ports:
        - protocol: TCP
          port: 8080

Once you enable a default-deny egress policy, remember to explicitly allow DNS (UDP/TCP 53 to kube-dns) or every name lookup breaks — a classic first-time pitfall. NetworkPolicy selects by Pod/namespace labels and CIDR, not IPs; for richer L7 (HTTP method/path) rules, use Cilium NetworkPolicy or a service mesh.

Secrets — encryption at rest

Kubernetes Secrets are not encrypted by default — they are stored base64-encoded in etcd, which is trivially reversible. Anyone with etcd access, an etcd backup, or broad get secrets RBAC can read them. Three layers of protection:

1. Encryption at rest — configure an EncryptionConfiguration on the API server so Secrets are encrypted before hitting etcd. Prefer a KMS provider (cloud KMS or Vault via the KMS plugin) over a locally-stored key, so the encryption key isn’t sitting on the control-plane node. Order providers with the encrypting one first; aescbc/secretbox are alternatives to KMS.
2. RBAC — treat get/list on secrets as highly privileged; scope it tightly. Reading a Secret is reading a credential.
3. External secret managers — keep the source of truth in AWS Secrets Manager, Vault, or GCP Secret Manager and sync into the cluster with the External Secrets Operator, or inject at runtime with the Secrets Store CSI driver — so secrets aren’t committed to Git and rotation is centralized. Never commit plaintext Secrets to Git; if you must store them in Git, seal them (Sealed Secrets) or encrypt with SOPS.

Image & supply-chain security

The container is only as trustworthy as the image and its provenance. A layered supply-chain defense:

• Scan images for known CVEs before and after deployment — Trivy, Grype, or the registry’s scanner — and fail the CI build on high/critical findings. Generate an SBOM (Syft) so you know what’s inside.
• Use minimal base images (distroless, Alpine, scratch) to shrink the attack surface — fewer packages, fewer CVEs, no shell for an attacker to use.
• Pin by digest (image@sha256:...), not mutable tags; :latest is unversioned and irreproducible.
• Sign images and verify at admission. Sign with cosign (Sigstore) at build time, then block unsigned or untrusted images at admission — Kyverno (verifyImages), Connaisseur, or the cloud’s built-in gate (GKE Binary Authorization, AWS Signer + ECR). This ensures only images your pipeline built and signed can run, defeating tampered or typosquatted images.
• Use a private registry with access controls and pull-through caching; avoid pulling arbitrary public images at runtime.

Best Practices

1. Enforce least-privilege RBAC and never bind cluster-admin broadly. Grant the minimum verbs on the minimum resources in the minimum scope. Audit with kubectl auth can-i --list and tools like rbac-lookup; treat verbs: ["*"], resources: ["*"], and broad secrets read as findings.

2. Give every workload a dedicated ServiceAccount and disable token automount when unused. Never grant permissions to the default SA. Set automountServiceAccountToken: false on Pods that don’t call the API, so a compromised Pod has no cluster credential to steal.

3. Use OIDC (your IdP) for human authentication, not client certs or shared tokens. Certs can’t be revoked cleanly and shared tokens can’t be attributed. OIDC gives central identity, group mapping, and revocation.

4. Enforce Pod Security Admission at restricted (or baseline minimum) on every workload namespace. Roll out with warn+audit first, fix violations, then enforce. Keep privileged only for vetted system namespaces.

5. Apply the hardened securityContext to every workload. runAsNonRoot, allowPrivilegeEscalation: false, readOnlyRootFilesystem: true, capabilities.drop: ["ALL"], and seccompProfile: RuntimeDefault. These are the concrete controls behind the restricted standard.

6. Never run privileged containers or mount the host filesystem/namespaces except for vetted infrastructure. privileged: true, hostPID, hostNetwork, and hostPath are container-escape vectors — block them with Pod Security and a policy engine.

7. Adopt default-deny NetworkPolicies and allow-list required flows. The flat, open-by-default network is a lateral-movement highway. Start with default-deny ingress+egress per namespace, then explicitly allow needed traffic — and remember to allow DNS.

8. Enable Secret encryption at rest with a KMS provider. base64 in etcd is not encryption. Encrypt before persistence, keep the key in cloud KMS/Vault, and tightly scope get secrets RBAC.

9. Keep secrets out of Git; use an external manager or sealed/encrypted secrets. Sync from Vault/Secrets Manager via the External Secrets Operator or Secrets Store CSI driver, or commit only Sealed Secrets/SOPS-encrypted values. Rotate centrally.

10. Scan images for CVEs in CI and continuously, and fail builds on critical findings. Use Trivy/Grype, generate an SBOM, and use minimal (distroless/scratch) base images to keep the attack surface small.

11. Sign images with cosign and verify signatures at admission. Enforce that only images built and signed by your pipeline can run, via Kyverno verifyImages, Binary Authorization, or Connaisseur — defeating tampered and typosquatted images.

12. Deploy a policy engine (Kyverno or Gatekeeper) for org-wide guardrails. Enforce rules Pod Security can’t express: forbid :latest, require resource limits and probes, restrict registries, mandate labels. Run in audit mode first to find existing violations.

13. Prefer in-cluster CEL ValidatingAdmissionPolicies or highly-available webhooks. A single-replica validating webhook is a cluster-wide outage risk — if it’s down, writes fail. Use ValidatingAdmissionPolicy (no external service) or run webhooks HA with a sane failurePolicy.

14. Bind ServiceAccounts to scoped cloud IAM roles (IRSA / Workload Identity). Never bake long-lived cloud access keys into Pods. Federate the SA token to a least-privilege cloud role so credentials are short-lived and per-workload.

15. Harden the cloud and cluster layers, not just workloads. Restrict API-server network access, keep the control plane and nodes patched, secure and back up etcd, enable audit logging, and enforce upgrades — the 4Cs mean an outer-layer weakness defeats inner-layer hardening.

16. Enable audit logging and runtime threat detection. Turn on the API-server audit log to know who did what, and run a runtime sensor (Falco, or a cloud/commercial equivalent) to catch container escapes, unexpected exec, and crypto-mining that admission-time controls can’t see.

References

• Overview of Cloud Native Security (the 4Cs)
• Kubernetes Security Concepts
• Authenticating
• Managing Service Accounts
• Using RBAC Authorization
• Admission Controllers Reference
• Dynamic Admission Control (webhooks)
• Validating Admission Policy (CEL)
• Pod Security Standards · Pod Security Admission
• Set the security context for a Pod/Container
• Network Policies
• Encrypting Secret Data at Rest
• Kyverno · OPA Gatekeeper
• Sigstore cosign · External Secrets Operator · Falco
• roadmap.sh — Kubernetes