Kubernetes Security Best Practices

Kubernetes automates the deployment and scaling of containers across a cluster of machines, but its flexibility creates a large, layered attack surface, which makes Kubernetes security a specialized concern. A single over-privileged service account or an unrestricted network path between pods can turn a minor foothold into full cluster compromise. Securing Kubernetes means hardening the control plane, constraining workloads, and carefully controlling the identities and network paths that connect them.

The Kubernetes Threat Model

A Kubernetes cluster has two broad parts, and attackers target both. The control plane includes the API server, the etcd datastore, the scheduler, and the controller manager. The worker nodes run the kubelet and the container runtime that host your pods.

Several properties shape the threat model:

• The API server is the single front door; nearly every action flows through it, so its authentication and authorization are critical.
• etcd stores the entire cluster state, including secrets, so it must be encrypted and locked down.
• By default, pods can reach one another freely, which enables lateral movement once any workload is breached.
• A compromised node exposes every pod scheduled on it, including their tokens and mounted secrets.

Because so much power converges on a handful of components, defense in depth is essential. No single control, whether authentication, authorization, or network policy, should be the only barrier between an attacker and the cluster. The sections below work through those layers in order, from identity to admission control.

Authentication and RBAC

Kubernetes separates authentication (who you are) from authorization (what you may do). Authentication can use client certificates, tokens, or an external identity provider through OIDC. Authorization is governed primarily by role-based access control (RBAC).

Sound RBAC practice follows least privilege:

• Grant narrowly scoped roles bound to specific namespaces rather than cluster-wide power.
• Avoid binding users or service accounts to the built-in cluster-admin role.
• Reject wildcard verbs and resources in roles, which quietly grant far more than intended.
• Give each workload its own service account, and disable automatic token mounting where a pod does not call the API.

Service account tokens deserve special care, because a pod that mounts a token can use it to call the API server, so a compromised container inherits whatever permissions that account holds. Keeping accounts narrowly scoped, turning off unnecessary token mounts, and preferring short-lived, audience-bound tokens all shrink what an attacker gains from a single breached pod. Enabling audit logging on the API server then records who performed which action, which is indispensable when reconstructing an incident later.

Restricting Workloads with Pod Security

Even correctly authorized workloads must run with limited privileges. The Pod Security Standards define three profiles, privileged, baseline, and restricted, and Pod Security Admission enforces the chosen profile at the namespace level. Individual pods are then constrained through their securityContext:

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
    - name: app
      image: registry.example.com/app@sha256:...
      securityContext:
        allowPrivilegeEscalation: false
        readOnlyRootFilesystem: true
        capabilities:
          drop: ["ALL"]

Running as non-root, dropping all capabilities, mounting a read-only root filesystem, and blocking privilege escalation together sharply limit what a compromised container can attempt.

Network Segmentation with Network Policies

Because pods communicate freely by default, network segmentation is one of the most impactful hardening steps. A NetworkPolicy lets you define which pods may talk to which, ideally starting from a default-deny posture and then allowing only required flows.

Effective segmentation includes:

• A default-deny policy per namespace so nothing is reachable unless explicitly permitted.
• Ingress rules that admit traffic only from the specific workloads that need it.
• Egress rules that restrict where pods can send data, containing exfiltration and callbacks.

Protecting Secrets and etcd

Kubernetes Secrets are only base64-encoded, not encrypted, in their default form. Anyone who can read a secret object or reach etcd can recover the plaintext. Protect them by enabling encryption at rest for etcd, restricting RBAC access to secret objects, and limiting which pods mount which secrets.

For stronger control, many teams integrate an external secrets system that injects short-lived credentials at runtime rather than storing long-lived values in the cluster, as covered in secrets management.

Admission Control and Supply Chain

Admission controllers intercept requests to the API server after authentication and authorization, and can validate or mutate them before objects are created. They are the enforcement point for organizational policy: rejecting privileged pods, requiring resource limits, blocking untrusted registries, or demanding signed images.

This dovetails with image-level hardening. Verifying provenance and scanning images before they reach the cluster, as described in container security, keeps known-bad workloads from ever being admitted.

Key Takeaways

• Treat the API server and etcd as crown jewels; every action and all secrets pass through them.
• Apply least-privilege RBAC, avoid cluster-admin bindings and wildcards, and give each workload its own service account.
• Enforce Pod Security Standards and set a restrictive securityContext with non-root users and dropped capabilities.
• Adopt default-deny NetworkPolicies to stop unrestricted pod-to-pod lateral movement.
• Encrypt etcd, treat Kubernetes Secrets as sensitive, and use admission control to enforce image and workload policy.