KubernetesContainersHardening

Container and Kubernetes Security Essentials

13 min readJune 29, 2026

Containers and Kubernetes default to convenience, not security. Images ship with known vulnerabilities, pods run as root, every pod can talk to every other pod, and service accounts often carry far more access than they need. This guide covers the high-leverage controls that close those gaps without re-architecting your platform: image hygiene, workload privilege reduction, network segmentation, and tight RBAC.

Image Hygiene and Provenance

Most container vulnerabilities arrive in the base image. Build on minimal base images (distroless or slim variants), scan images for known CVEs in CI and fail the build on critical findings, and pull only from trusted registries. Rebuild and redeploy regularly so patched base layers actually reach production — an image scanned clean at build time accumulates vulnerabilities as new CVEs are disclosed.

Build on minimal or distroless base images to shrink the attack surface
Scan images in CI and fail on critical, fixable vulnerabilities
Pull only from trusted, access-controlled registries
Rebuild on a cadence so base-image patches reach production

Drop Privileges in the Pod Spec

A container that runs as root and can write to its own filesystem gives an attacker who achieves code execution a much easier path to escalate. Enforce a restrictive securityContext on every workload: run as a non-root user, use a read-only root filesystem, drop all Linux capabilities, and disallow privilege escalation. These constraints rarely break well-behaved applications and dramatically raise the cost of container escape.

k8s/deployment.yaml

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

tip

Enforce these defaults cluster-wide with Pod Security Admission (restricted profile) so a single misconfigured manifest cannot ship a privileged pod.

Segment Traffic with Network Policies

By default every pod in a Kubernetes cluster can reach every other pod. A single compromised workload can then scan and pivot across the whole cluster. Apply NetworkPolicies that default-deny ingress and egress, then explicitly allow only the connections each service actually needs. This contains lateral movement so a breach in one namespace cannot trivially reach your databases or internal APIs.

warning

A default-deny network policy is only enforced if your CNI plugin supports NetworkPolicy. Confirm enforcement in a test namespace before relying on it.

Scope RBAC and Service Accounts

Kubernetes RBAC and service-account tokens are frequent over-grants. Give each workload its own service account with only the API permissions it needs, disable automatic token mounting where it is not required, and avoid binding workloads to cluster-admin. Audit Roles and ClusterRoles regularly for wildcard verbs and resources — those are the bindings an attacker hopes to find on a token they have stolen.

Give each workload a dedicated, least-privilege service account
Disable automountServiceAccountToken where the pod does not call the API
Avoid wildcard verbs/resources in Roles and ClusterRoles
Review bindings for unintended cluster-admin grants

Hardening CI/CD Pipelines and the Software Supply Chain

Lock down GitHub Actions and your build pipeline: pin actions to SHAs, scope tokens to least privilege, and keep secrets out of logs.

14 min read

CI/CDSupply ChainGitHub Actions

Zero Trust Access: Replacing the VPN and Closing Down SSH

Move from a flat, perimeter-based network to identity-aware access — closing public SSH and putting every internal service behind authenticated, audited policy.

12 min read

Zero TrustAccess ControlSSH

Secrets Management: Centralization, Encryption, and Rotation

Get secrets out of .env files and git history into a managed, encrypted, auditable system — and make rotation routine rather than an emergency.

11 min read

SecretsEncryptionCompliance