PS Product SecurityKnowledge Base

☸️ Kubernetes Security Baseline

Kubernetes baseline control map

Intro: Kubernetes security works best as a stack of reinforcing controls: Pod posture, identity, network, admission, runtime, and auditability. Baselines should be designed so teams can adopt them progressively without leaving risky defaults in place forever.

Baseline control families

1. Pod posture

Use a security context that makes unsafe defaults explicit.

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

2. Pod Security Admission

Use namespace labels to phase posture into enforcement.

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

3. Default-deny network stance

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: payments
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

4. Service account minimization

If the application does not need the token, disable automatic mounting.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments-api
spec:
  template:
    spec:
      automountServiceAccountToken: false

5. Resource protection

Use requests, limits, and namespace-level resource policies to reduce noisy-neighbor and denial-of-service problems.

Baseline rollout order

  1. inventory current privilege exceptions;
  2. warn and audit first;
  3. enforce by namespace tier;
  4. move to default-deny networking;
  5. reduce service account exposure;
  6. restrict trusted image sources;
  7. enable audit logging and central aggregation;
  8. review exceptions on a schedule.

Frequent mistakes

  • Pod Security Admission remains in audit mode forever;
  • the chosen CNI does not actually enforce NetworkPolicy the way the team expects;
  • the default service account token is mounted in nearly every workload;
  • privileged workloads live in shared application namespaces;
  • broad RBAC rights exist for convenience;
  • secrets remain unencrypted or overexposed;
  • control-plane access is reachable from untrusted networks.

A better baseline checklist

  • workloads run as non-root unless there is a documented exception;
  • read-only root filesystems used where practical;
  • privilege escalation disabled by default;
  • host namespace and host path usage tightly controlled;
  • default-deny network policy in each application namespace;
  • service account token mounting minimized;
  • RBAC roles separated for developers, operators, admins, and workloads;
  • audit logging enabled and shipped off-cluster;
  • patch, scan, and review loop defined.

Footer