Kubernetes Security Overview

Kubernetes Threat Model

Kubernetes clusters are complex distributed systems with a large attack surface. Understanding what can go wrong drives the security architecture. The Kubernetes threat model covers adversaries who are:

• External attackers — no access to the cluster; attempting to reach exposed services or the API server
• Internal network attackers — compromised a node or pod; attempting lateral movement within the cluster
• Malicious tenants — legitimate cluster users attempting privilege escalation to other namespaces or the host
• Supply chain attackers — compromised a container image, Helm chart, or operator to gain execution inside the cluster

STRIDE Analysis

The 4C Security Model

The 4C model (Cloud, Cluster, Container, Code) describes a layered security approach. Each outer layer protects the layers within it, but a vulnerability at any layer can undermine the protections of the layers it contains.

┌────────────────────────────────────────────────────────────────┐
│                           CLOUD                                │
│  IAM roles, VPC network ACLs, node firewall rules,            │
│  cloud provider encryption, managed control plane TLS          │
│                                                                │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │                        CLUSTER                           │  │
│  │  API server auth/authz, RBAC, admission controllers,     │  │
│  │  etcd encryption, network policies, audit logging        │  │
│  │                                                          │  │
│  │  ┌────────────────────────────────────────────────────┐  │  │
│  │  │                    CONTAINER                       │  │  │
│  │  │  Pod Security (seccomp, AppArmor, capabilities),   │  │  │
│  │  │  non-root execution, read-only rootfs, Falco       │  │  │
│  │  │                                                    │  │  │
│  │  │  ┌──────────────────────────────────────────────┐  │  │  │
│  │  │  │                  CODE                        │  │  │  │
│  │  │  │  SAST, dependency scanning, image signing,   │  │  │  │
│  │  │  │  SBOM, Sigstore provenance, secret scanning  │  │  │  │
│  │  │  └──────────────────────────────────────────────┘  │  │  │
│  │  └────────────────────────────────────────────────────┘  │  │
│  └──────────────────────────────────────────────────────────┘  │
└────────────────────────────────────────────────────────────────┘

Attack Surface Map

EXTERNAL                          CLUSTER INTERNAL
─────────                         ──────────────────
kubectl / CI/CD ──► API Server ──► etcd (CRITICAL — encrypt + TLS client auth)
                        │
                        ├──► Controller Manager (in-cluster RBAC)
                        ├──► Scheduler (in-cluster RBAC)
                        └──► Kubelet API (port 10250)
                                    │
                             ┌──────┴──────┐
                             │  Node OS    │
                             │  Container  │
                             │  Runtime    │
                             └─────────────┘
                                    │
                             ┌──────▼──────┐
                             │   Pods      │
                             │ ServiceAcct │──► cloud IAM via IRSA/Workload Identity
                             └─────────────┘

High-Value Targets

Defense-in-Depth Layers

Authentication & Authorization

Authentication Methods

Authorization Modes

The API server evaluates authorization modes in the order specified by --authorization-mode. A request is allowed if any mode permits it (short-circuit on first Allow).

Admission Control Pipeline

After a request passes authentication and authorization, it passes through the admission control pipeline before being persisted to etcd:

Request → AuthN → AuthZ → Mutating Admission → Object Schema Validation → Validating Admission → etcd
                              │                                                      │
                     MutatingWebhookConfigurations                   ValidatingWebhookConfigurations
                     Pod Security Admission (mutate)                 Pod Security Admission (validate)
                     LimitRanger                                      OPA/Gatekeeper
                     ServiceAccount token injection                   Kyverno
                     NamespaceLifecycle                               ResourceQuota

Key built-in admission plugins (enabled by default or recommended):

Workload Isolation

Pod Security Standards

Pod Security Admission (PSA) enforces three built-in policy levels per namespace, applied via the label pod-security.kubernetes.io/enforce. See 02-pod-security.html for the full field-by-field breakdown.

Namespace Tenancy Model

Namespaces provide a soft isolation boundary — they scope RBAC, ResourceQuota, NetworkPolicy, and PSA. They do not provide hard multi-tenancy; a privileged workload in any namespace can reach the host. For stronger isolation, use separate clusters or hierarchical namespace controllers (HNC).

kubectl label namespace my-app \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted

Key Pod-Level Security Fields

CopysecurityContext:                      # Pod-level
  runAsNonRoot: true
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  seccompProfile:
    type: RuntimeDefault               # or Localhost with custom profile
  sysctls: []                          # avoid privileged sysctls

containers:
  - securityContext:                   # Container-level (overrides pod-level)
      allowPrivilegeEscalation: false  # prevent setuid/sudo escalation
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
        add: ["NET_BIND_SERVICE"]      # only if port < 1024 needed
      seccompProfile:
        type: RuntimeDefault

Network Security

Default-Deny Pattern

Without Network Policies, all pods can communicate freely within a cluster. The correct default is to deny all ingress and egress, then explicitly allow required flows. See 03-network-policies.html for full examples.

Copy# Apply to every tenant namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}          # matches all pods
  policyTypes:
  - Ingress
  - Egress
  # no ingress/egress rules = deny all

mTLS for Service-to-Service

NetworkPolicy operates at L3/L4 (IP + port). For L7 identity-based traffic control and end-to-end encryption, use a service mesh (Istio, Linkerd, Cilium's mesh mode). mTLS provides:

• Mutual authentication — both sides verify identity via SPIFFE SVID certs
• Encryption in transit — all service traffic encrypted, even within the same node
• Fine-grained AuthorizationPolicy — "service A may only call service B's /api/v1 endpoint"

Secrets & Supply Chain

Secret Storage Risk Hierarchy

Supply Chain Attack Vectors

• Compromised base image — malicious code in public Docker Hub image
• Dependency confusion — internal package name shadowed by public malicious package
• Typosquatting — alpine-3.18 vs alipne-3.18 in Dockerfile
• Compromised CI pipeline — attacker injects code during build, before signing
• Untrusted Helm charts — public chart installs ClusterRoleBinding with cluster-admin

See 10-supply-chain-security.html for Sigstore/cosign signing workflow, SBOM generation with Syft, and admission policy enforcement with Kyverno image verification.

Runtime Security

Linux Kernel Security Mechanisms

Falco — Behavioral Runtime Detection

Falco (CNCF) monitors kernel syscalls via eBPF/kernel module and alerts on policy violations at runtime. Key default rules:

• Shell spawned in container (exec of bash/sh/zsh)
• Write to /etc or /usr directories
• Network connection from unexpected process
• Sensitive file reads (/etc/shadow, /etc/kubernetes/pki/...)
• Container privilege escalation attempt
• K8s audit event for sensitive operations (secret reads, exec into pods)

Compliance & Audit

Kubernetes audit logging records every API server request at configurable verbosity levels. Logs should be shipped to immutable storage (S3, Elasticsearch, Splunk) off-cluster immediately. See 08-audit-logging.html for audit policy examples.

Compliance Frameworks

See 11-compliance.html for compliance automation tools (kube-bench, Polaris, Kubescape).

Security Hardening Checklist

Control Plane

Nodes

Workloads

CIS Benchmark Key Controls Summary

The CIS Kubernetes Benchmark (Center for Internet Security) is the most widely adopted prescriptive hardening guide. Run kube-bench to automatically check your cluster against the benchmark. Key sections:

Copy# Run kube-bench in-cluster
kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

# Or run as a pod targeting specific benchmark
kubectl run kube-bench --image=aquasec/kube-bench:latest \
  --restart=Never -- node --benchmark cis-1.8

Best Practices

1. Apply the 4C model systematically. Don't rely on cluster security alone. Harden the cloud layer (IAM, VPC), the container layer (seccomp, capabilities), and the code layer (SAST, image scanning) independently.
2. Enforce Pod Security Standards at the restricted level for all non-system namespaces. Use enforce mode (not just warn) on all workload namespaces. Reserve privileged level for kube-system and node agent namespaces only.
3. Use short-lived, bound service account tokens. Disable legacy auto-mounted tokens (automountServiceAccountToken: false on default ServiceAccount per namespace). Inject tokens only for pods that need API server access, using projected volumes with a 1h audience-bound expiry.
4. Encrypt secrets at rest and prefer external secret stores. etcd encryption at rest protects stolen backups; an external store (Vault, AWS SSM) additionally prevents secrets from residing in etcd at all. Use IRSA/Workload Identity for cloud-native secret retrieval without static credentials.
5. Implement default-deny NetworkPolicy in every tenant namespace. Then explicitly allow required ingress/egress. This prevents east-west lateral movement after a container compromise.
6. Sign all images with cosign and enforce policy in admission. A Kyverno ClusterPolicy or OPA Gatekeeper constraint should reject pods using unsigned images from unauthorized registries. This blocks most supply chain attacks.
7. Ship audit logs off-cluster immediately to immutable storage. A compromised cluster admin can delete on-cluster audit logs. Ship to an external SIEM (Splunk, Elasticsearch, CloudWatch) with a write-once policy.
8. Run CIS kube-bench and address all Level 1 failures before production. Automate kube-bench as part of cluster provisioning CI. Re-run after every control plane upgrade. Track benchmark drift in a dedicated Grafana dashboard.