Container and Kubernetes Security Hardening in Practice

Kubernetes is an API-driven platform, and the control plane, the Kubelet, and workloads can all become attack surfaces. The official "Securing a Cluster" document lays out a clear principle: first control who can reach the API, then limit what workloads can do at runtime, and finally protect critical components like etcd. For the supply-chain side such as image scanning, see Container Security Best Practices.

In practice, most clusters are not broken into by "advanced attacks" — they fall to default configuration: anonymous access left open, an exposed kubelet, over-privileged ServiceAccounts, and Secrets stored in plaintext in etcd. Once an attacker has a single Pod's permissions, they can escalate through these default gaps. The sections below harden layer by layer in the order: identity → runtime → data → automation.

Control plane access: authentication and authorization

TLS: all API traffic uses TLS by default; confirm your installer does not expose plaintext HTTP ports.
Authentication: larger clusters integrate OIDC or LDAP; infrastructure clients such as nodes and proxies use x509 certificates or Service Accounts.
Authorization: enable RBAC with least privilege, and enable the Node and NodeRestriction admission plugins to limit kubelet and node permissions.
Kubelet: it allows unauthenticated access by default; enable its authentication and authorization in production.

A Least-Privilege RBAC Example

Instead of handing a developer a "cluster read-only" role, grant only the resource permissions they need within their namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: app
  name: app-developer
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: app
  name: dev-binding
subjects:
  - kind: User
    name: [email protected]
roleRef:
  kind: Role
  name: app-developer
  apiGroup: rbac.authorization.k8s.io

A Role plus RoleBinding only applies to a single namespace — a much smaller blast radius than ClusterRole plus ClusterRoleBinding. Audit existing permissions with kubectl auth can-i --list and spot oversized bindings with kubectl get clusterrolebinding -o wide.

Workload runtime security

Security Context: run application containers as a non-root user and drop unnecessary capabilities.
Pod Security Standards: enable Pod Security admission per namespace, targeting Baseline or Restricted.

Enabling Pod Security admission is just a namespace label; Kubernetes then rejects non-compliant Pods automatically:

kubectl label --overwrite ns app pod-security.kubernetes.io/enforce=restricted
kubectl label --overwrite ns app pod-security.kubernetes.io/audit=restricted

enforce rejects outright while audit only logs warnings. Add audit first, observe for a while, then switch to enforce to avoid breaking existing workloads.

Kernel modules: blacklist problematic modules such as dccp and sctp via /etc/modprobe.d/, or use SELinux to deny module_request.
Network policies: use NetworkPolicy to restrict cross-namespace access and block Pod access to the cloud metadata API (169.254.169.254).
Resource limits: use ResourceQuota and LimitRange to prevent resource-exhaustion attacks.

Protecting critical components

etcd: allow only the API Server to reach it with mutual TLS; read/write access to etcd is equivalent to cluster-admin.
Audit logging: enable API auditing and archive it to a secure server, integrated with Security Log Auditing.
Encryption at rest: enable etcd encryption at rest for Secrets/ConfigMaps to protect against backup leaks.

Enable it by adding --encryption-provider-config to the API Server startup flags, pointing at an encryption config file containing an AES-GCM key. Once active, new Secrets are written to etcd as ciphertext; existing data needs a one-time rewrite with a rotation script.

Credential rotation: give certificates and Service Account tokens short lifetimes and rotate them automatically.
Third-party integrations: review their permissions before enabling; beware of components that request access to all Secrets, which effectively makes them cluster admins.

Hardening Priority and Rollout Order

When resources are limited, this order yields the highest return:

Identity first: disable anonymous access, enable RBAC and NodeRestriction, tighten the kubelet.
Limit runtime next: force non-root, enable Pod Security admission up to Restricted, restrict capabilities and seccomp.
Protect data later: enable etcd encryption at rest, etcd network isolation, and audit logging.
Automate last: codify the rules above as Policy-as-Code and re-review them as the cluster version upgrades.

Image and Supply-Chain Security

Put image scanning into the build pipeline and block releases on critical vulnerabilities, see Container Security Best Practices.
Use trusted base images with pinned versions to avoid "latest" drift.
Enable image signing and immutable tags to prevent replacement injection.

Common Risk Flags

Read/write access to etcd is roughly equivalent to cluster-admin; minimize it and isolate the network.
Treat any third-party component that requests "read all Secrets" with high suspicion — that equals cluster-admin.
Integrations allowed to create privileged Pods in system namespaces are a common container-escape path.

Pre-Production Checklist

Before handing the cluster to business workloads, confirm each item: API Server over TLS, anonymous access disabled, RBAC minimized, Pod Security admission enabled, etcd encrypted and network-isolated, and audit logs archived. Every item can be verified quickly with commands such as kubectl auth can-i --list and kubectl get psa, turning "secure by default" into a routine release gate. Turn this checklist into a team SOP: run through it item by item whenever you create a namespace or onboard a new workload, rather than revisiting it after something goes wrong.

16IDC Observation

The key to Kubernetes security is not any single tool but a default posture of "least privilege plus defense in depth". Small teams can start with namespace isolation, Pod Security Standards, and image scanning, then progress to RBAC auditing and etcd encryption. For an introductory deployment see Kubernetes Deployment for Beginners. Browse the full framework back in the Security Hardening category.

Reference: Kubernetes Securing a Cluster https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/; Pod Security Standards https://kubernetes.io/docs/concepts/security/pod-security-standards/; NSA/CISA Kubernetes Hardening Guidance https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF

Source: https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/

Container and Kubernetes Security Hardening in Practice