Kubernetes Security Hardening

Kubernetes is secure by configuration, not by default. A fresh cluster will happily run privileged pods, allow all pod-to-pod traffic, and hand broad permissions to service accounts. Hardening is about removing those defaults layer by layer so a single mistake or compromise doesn't become a cluster-wide incident.

1. RBAC: least privilege, no wildcards

Start from zero and grant only what each identity needs. Avoid cluster-admin bindings and wildcard * rules. Scope Roles to namespaces wherever possible and reserve ClusterRoles for genuinely cluster-wide needs.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata: { namespace: catalog, name: catalog-reader }
rules:
  - apiGroups: [""]
    resources: ["pods", "configmaps"]
    verbs: ["get", "list", "watch"]   # no create/delete/*

2. Enforce Pod Security Standards

Apply the restricted Pod Security Standard at the namespace level. It blocks privilege escalation, host namespaces, and running as root — the controls that matter most for container breakout.

apiVersion: v1
kind: Namespace
metadata:
  name: catalog
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

In pod specs, drop all capabilities, run as non-root, and use a read-only root filesystem:

securityContext:
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities: { drop: ["ALL"] }

3. Default-deny network policies

By default every pod can talk to every other pod. Flip that: apply a default-deny ingress policy per namespace, then allow only the flows each service needs.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: default-deny, namespace: catalog }
spec:
  podSelector: {}
  policyTypes: ["Ingress"]

4. Get secrets out of the cluster

Native Kubernetes Secrets are only base64-encoded. Pull real secrets from AWS Secrets Manager or Google Secret Manager via the Secrets Store CSI driver or External Secrets Operator, and enable encryption at rest for etcd.

5. Identity without static keys

Use IRSA on EKS and Workload Identity on GKE so pods assume cloud IAM roles directly. No mounted service-account JSON, no long-lived keys to leak.

6. Secure the supply chain

Scan images for CVEs in CI, pull from a private registry, and enforce provenance with admission control — OPA Gatekeeper or Kyverno to require signed images, block :latest, and mandate resource limits.

# Kyverno: disallow latest tag
validationFailureAction: Enforce
rules:
  - name: disallow-latest-tag
    match: { resources: { kinds: ["Pod"] } }
    validate:
      message: "Using ':latest' is not allowed"
      pattern: { spec: { containers: [{ image: "!*:latest" }] } }

Hardening checklist

• RBAC least privilege — no wildcards, no stray cluster-admin
• Restricted Pod Security Standard enforced per namespace
• Non-root, no privilege escalation, read-only rootfs, drop ALL caps
• Default-deny network policies, allow-list per service
• External secret store + etcd encryption at rest
• IRSA / Workload Identity — no static keys in pods
• Image scanning + admission control (Gatekeeper / Kyverno)

Continuous checks for exactly these controls — RBAC sprawl, privileged pods, public exposure — are core to ATechsCloud CloudOps.