Security Primer¶

Assumes: the whole Beginner track up to here - pods, services, namespaces, and configuration. This is the last page in it.

Kubernetes security is a layered discipline, not a single feature.

A practical model is to protect each layer of the stack and assume controls can fail independently.

Major risk areas¶

excessive RBAC (Role-Based Access Control) permissions - the system that decides which users and workloads may read or change which objects
privileged or poorly constrained containers
weak image supply-chain controls
unrestricted lateral (east-west) network traffic - traffic between workloads inside the cluster, as opposed to traffic entering it
missing audit visibility and incident response readiness

4-layer security model¶

This is our variant of the CNCF's well-known "4 Cs of Cloud Native Security" (Cloud, Cluster, Container, Code) - we use Workload and Application in place of Container and Code to match this site's terminology, but the layered idea is the same.

graph TD
    A[Cloud\nIAM identity · network segmentation · KMS key management · managed audit logs]
    B[Cluster\nRBAC · admission controls · etcd encryption · API audit logs]
    C[Workload\npod security standards · security context · network policy]
    D[Application\ndependency scanning · secrets hygiene · secure SDLC]

    A --> B --> C --> D

Three acronyms in that diagram, in plain terms: IAM is your cloud provider's identity and access management (who your cluster's nodes and controllers are allowed to be in the cloud account); KMS is a key management service, used here to encrypt Secrets at rest; SDLC is the software development lifecycle, meaning the checks that run in your build pipeline before anything reaches a cluster.

A breach at any inner layer is harder to contain if the outer layers are weak. Treat each layer as independently enforceable - do not rely on the application layer to compensate for weak cluster controls.

Security operating baseline¶

enforce least privilege access
harden workload defaults
restrict unnecessary east-west traffic
verify artifact integrity before deploy
collect and retain actionable audit and runtime telemetry

One concrete example: hardening a single Deployment¶

Everything above is abstract until you see it in a manifest. Here is a perfectly ordinary Deployment, and the same one after applying the baseline:

# Before
spec:
  template:
    spec:
      containers:
        - name: web
          image: ghcr.io/example/web:latest

# After
spec:
  template:
    spec:
      serviceAccountName: web            # cluster layer: its own identity, not "default"
      automountServiceAccountToken: false # cluster layer: no API token in the pod at all
      containers:
        - name: web
          image: ghcr.io/example/web@sha256:0f2a...  # application layer: pinned, verifiable artifact
          securityContext:                # workload layer
            runAsNonRoot: true
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop: ["ALL"]

Mapped to the four layers:

serviceAccountName and automountServiceAccountToken are cluster layer - they decide what this pod can ask the API server to do. The default service account plus an auto-mounted token is how a compromised container starts talking to the API.
runAsNonRoot, allowPrivilegeEscalation, readOnlyRootFilesystem and dropping all capabilities are workload layer - they shrink what the process can do on the node if it is compromised.
The digest-pinned image is application layer - it makes the artifact you scanned and signed the same artifact that runs.
The cloud layer is not visible in this YAML at all, which is exactly the point: node IAM roles and network segmentation are set outside the manifest, and a tight pod spec does not save you from a node with an over-permissive instance profile.

Nothing here needs a policy engine. It is five fields, and it removes most of the easy paths from "attacker has code execution in one container" to "attacker has the cluster."

Admission controllers¶

Admission webhooks provide a powerful enforcement point between "request accepted by API server" and "object written to etcd." Two common policy engines:

Kyverno: Kubernetes-native policy engine using YAML-based policies. Good fit for teams that want policy-as-code without a new DSL.
OPA/Gatekeeper: Open Policy Agent with the Gatekeeper admission controller. Uses Rego policy language. More expressive for complex constraints.

Both support validate (reject non-compliant objects) and mutate (inject defaults or required fields) policies.

Security in the delivery pipeline¶

Security should run before deploy, not only after incidents.

Recommended controls in CI and CD:

manifest linting and policy checks (e.g. kube-score, trivy config)
image scanning and signing
admission policy verification (dry-run against policy engine before merge)

Continuous improvement loop¶

review new cluster and namespace permissions regularly
test incident response playbooks
patch and rotate credentials on a schedule
run periodic architecture threat reviews

Check Yourself¶

A pod is compromised. Why does automountServiceAccountToken: false change how bad that is?

Without it, every pod gets a mounted token for its namespace's service account, so code execution in the container immediately becomes an authenticated API client. What it can then do depends entirely on RBAC. Turning the mount off for workloads that never call the API removes that pivot outright.

You enforce Pod Security Standards on every namespace. Which of the four layers is still completely unaddressed?

Cloud, and largely application. Pod Security Standards are a workload-layer control: they constrain what pods may declare. They do nothing about node IAM roles, network segmentation, KMS encryption of Secrets, or whether the image you are running contains a known-vulnerable dependency.

Why does the order of the admission pipeline mean a mutating webhook is more dangerous than a validating one?

Mutating admission runs first and can rewrite the object. Everything downstream - schema validation, policy engines, your own validating rules - sees the rewritten version, not what you submitted. A compromised or buggy mutating webhook can therefore inject something that all later checks then bless.

Your CI pipeline scans images and blocks vulnerable ones. Is scanning at admission time redundant?

No. CI proves something about the artifact your pipeline built; admission proves something about the artifact actually being scheduled. They differ whenever a manifest is applied by hand, a mutable tag is repointed, or an image comes from outside your pipeline. Layers are meant to fail independently.

Namespaces separate two teams. Team A's pod is compromised. What stops it reaching Team B's database pod?

By default, nothing. Namespaces partition names and policy scope, not the network. Restricting that lateral path takes a NetworkPolicy (and a CNI that enforces it) - which is the network segmentation item in the operating baseline above.

You have finished the Beginner track¶

Twelve pages back you started with a reconciliation loop. You now have the working set: how the cluster converges on desired state, how to get a local cluster, Pods and Deployments, probes, the pod network and Services, namespaces, configuration and Secrets, requests and autoscaling, the API server, and the security layers above.

Three honest options from here:

You write applications that run on Kubernetes. Take the Developer track - storage, jobs, Ingress, and the packaging tools, ending at the CKAD.
You operate the clusters themselves. Take the Operator / Admin track - the control plane, scheduling, maintenance, and cluster networking, ending at the CKA. Security specialization (CKS) branches from here, not from this page.
Stop here. If your job is reading manifests and reasoning about someone else's cluster, this is genuinely enough. Come back to Troubleshooting and the Kubectl Cheat Sheet when something breaks.

Core Kubernetes Security Topics¶

Learning Paths - where this page sits in your track
Namespaces - the scope most of these controls attach to
Network Policies - the east-west restriction named in the baseline
OPA & Gatekeeper - enforcing these baselines automatically as admission policy

Summary¶

Secure Kubernetes operations come from consistent controls across identity, runtime, network, and supply chain. Treat security as an operational system, not a one-time project.

Beginner track - step 12 of 12, the last page. Back to the track overview to pick your next track.