aegis-kubernetes-cluster-hardening

Imported from AS-FOSS/aegis-skills (skills/server/kubernetes-cluster/SKILL.md). Install upstream with npx skills add AS-FOSS/aegis-skills --skill kubernetes-cluster. Copyright stays with the author.

Scope & Objectives

Audit one Kubernetes cluster — or its config-as-code repository (plain manifests, Helm charts, Kustomize overlays) — in eight domains:

1. Cluster access & API server — kubeconfig hygiene, self-inspection of effective permissions, anonymous-auth and legacy insecure-port exposure, etcd encryption-at-rest presence.
2. RBAC — wildcard rules, anonymous bindings, cluster-admin holder count, default ServiceAccount token automounting, privilege-escalation primitives (escalate, bind, impersonate, serviceaccounts/token).
3. Admission control & policy — PodSecurity admission labels per namespace; PodSecurityPolicy as legacy-only detection; policy engines (Kyverno, Gatekeeper) noted qualitatively.
4. Workload securityContext — cluster-wide coverage sweep of runAsNonRoot, allowPrivilegeEscalation, readOnlyRootFilesystem; privileged containers; hostPath, hostNetwork/hostPort/hostPID hunts. Deep pod-spec hardening lives in the configuration-hardening module — do not duplicate it here beyond the cluster-level view.
5. NetworkPolicy posture — default-deny presence per namespace, egress rarity, DNS allowance gotcha.
6. Secrets handling in-cluster — env-var vs volume-mount tradeoff, etcd-encryption tie-in, external operators (ExternalSecrets/SealedSecrets) named generically.
7. Ingress/LB exposure & observability — public vs internal classes, TLS termination, NodePort sprawl, audit-policy existence, event review discipline.
8. Node baseline pointers — kubelet authorization mode and read-only port when node-visible, with a one-line hand-off to the linux-baseline module.

Operating rules:

• Every command is read-only: get, list, describe, auth can-i, file reads, greps. Never run apply, delete, create token, exec, or port-forward during audit. Mutating commands appear only under Remediation and Verification, inside an approved change window.
• The live cluster and its Git repo are two views of one system. Audit both; reconcile drift (repo says restricted, cluster says privileged → someone applied out-of-band).
• On managed clusters (GKE/EKS/AKS), control-plane flags and EncryptionConfiguration are provider-managed and invisible from workload context. Audit what is auditable from your identity and record the limitation explicitly in the report — absence of evidence is not evidence of safety there.

Prerequisites & Vocabulary

Zero-background primer: the terms this module uses, one line each. Deeper plain-language explanations for every class live in the repository GUIDE.md glossary.

• namespace: a cluster partition grouping workloads and their policies
• RBAC: rules binding identities to allowed verbs on resources (get, list, exec, …)
• ServiceAccount token: the identity file mounted into every pod; whoever can run commands in a pod holds it
• automount: the default-ON behavior of mounting that token into pods
• admission: policies that validate or modify objects before they are created
• NetworkPolicy: a per-namespace firewall; where none exists, any pod can reach any pod
• etcd: the cluster's database holding all Secrets, base64-encoded unless encryption-at-rest is enabled
• taint flow / source→sink: path untrusted data travels from entry point to dangerous function

Mental Model

Every capability in Kubernetes is an API request: verb on resource in apiGroup, scoped to a namespace. The request path is the audit map:

Client ──▶ Authentication ──▶ Authorization (RBAC) ──▶ Admission ──▶ etcd
           x509 / bearer /     verbs × resources ×      mutating then
           OIDC / anonymous    namespaces               validating
                                                        (PodSecurity,
                                                         Kyverno/Gatekeeper)

Consequences that drive every check below:

• Identity is a mounted file. A pod's ServiceAccount token is projected into the container at /var/run/secrets/kubernetes.io/serviceaccount/token unless automountServiceAccountToken: false. Whoever can exec into a pod holds its identity. Default is automount = on.
• The network is flat until denied. Any pod can reach any pod in any namespace by IP unless a NetworkPolicy blocks it. Ingress+egress default-deny per namespace is the baseline; egress policies are rarer and must always carve out DNS.
• RBAC is transitive through tokens. Escalation primitives (escalate, bind, impersonate, create serviceaccounts/token) let a low identity mint or borrow a higher one. Chain severity = the ceiling of what the chain reaches, not the starting point.
• etcd is the crown jewels. All Secrets live there, base64-encoded, encrypted only if an EncryptionConfiguration (or provider feature) is active. Anyone who can read etcd bypasses RBAC entirely.
• cluster-admin is total compromise. One wildcard binding to a workload identity means every Secret, exec into every pod, privileged DaemonSets on every node. Count and justify each holder.

What To Check

1. Cluster access & API server

Cluster-admin count reasoning: enumerate holders, then classify each subject. Expect only platform identities (cloud add-on service accounts, system:masters group members) plus a small break-glass human list. Every workload ServiceAccount bound to cluster-admin is Critical; every broad human group is High until justified in writing.

# Holder inventory + classification (read-only)
command -v kubectl >/dev/null 2>&1 || exit 0
kubectl get clusterrolebindings -o json 2>/dev/null \
  | jq -r '.items[] | select(.roleRef.name=="cluster-admin") |
           .metadata.name as $b |
           (.subjects // [])[]? |
           "\($b)\t\(."kind")\t\(."name")\t\(."namespace" // "-")"' \
  | sort

Anonymous-auth exposure check on managed clouds: node-level static-pod manifests do not exist there. Fall back to the behavioral curl test above against the provider endpoint and record that control-plane flags cannot be inspected directly.

2. RBAC

# Wildcard rules in non-system ClusterRoles (read-only)
kubectl get clusterroles -o json 2>/dev/null | jq -r '
  .items[]
  | select((.metadata.name | startswith("system:") | not)
           and ((.metadata.name | startswith("kubeadm:")) | not))
  | select(any(.rules[]?;
      ((.verbs     // []) | index("*"))
      or ((.resources   // []) | index("*"))))
  | .metadata.name'

Privilege-escalation primitives catalog — treat each row as an escalation primitive, verified by reading rule blocks:

Service-account-token-request escalation chain (understand it; verify statically):

1. Attacker holds a token for app SA A (stolen from a compromised pod's projected volume).
2. A's Role grants create on serviceaccounts/token in namespace N.
3. Any stronger SA exists in N (for example a CI deployer with cluster-wide rights).
4. A issues a TokenRequest for that SA — kubectl create token <sa> -n N semantics — receiving a fresh bearer token.
5. The attacker now operates as the stronger SA; repeat until cluster-admin or stop at the widest reachable role.

Audit verification is steps 1–3 done by reading: list SAs, dump Roles/Bindings, map who can mint whom. Never run step 4 during an audit — issuing credentials is a mutating action.

Per-namespace least privilege framing: default expectation is that a workload SA resolves to zero cross-namespace rights and single-digit same-namespace rights. Anything wider needs a written reason attached to the finding.

3. Admission control & policy

Exact label keys to look for on namespaces: pod-security.kubernetes.io/enforce, pod-security.kubernetes.io/enforce-version, pod-security.kubernetes.io/warn, pod-security.kubernetes.io/warn-version, pod-security.kubernetes.io/audit, pod-security.kubernetes.io/audit-version. Values: privileged, baseline, restricted (or version pins). warn/audit labels without enforce mean the standard is advisory only — report as Medium, not healthy.

4. Workload securityContext (cluster-wide view)

Deep per-container hardening detail belongs to the configuration-hardening module; here measure coverage across the whole fleet.

5. NetworkPolicy posture

Egress NetworkPolicies are uncommon because they break things subtly. If none exist, record it and point remediation at the staged approach used by the firewall-edge module philosophy: observe, then allow known flows, then deny. Never flip straight to deny-all egress.

6. Secrets handling in-cluster

Env vars trade convenience for leakage surface: they appear in kubectl describe pod, child processes, and crash dumps; mounted Secret volumes update on rotation and need explicit file reads to exfiltrate.

7. Ingress/LB exposure

8. Audit logging & observability

9. Node baseline pointers

Consolidated read-only sweep

Paste-ready. Guards its own prerequisites; mutates nothing; skips cleanly when tooling or RBAC is missing.

#!/usr/bin/env bash
# Kubernetes posture sweep — strictly non-mutating.
command -v kubectl >/dev/null 2>&1 || { echo "SKIP: kubectl missing"; exit 0; }
command -v jq      >/dev/null 2>&1 || { echo "SKIP: jq missing"; exit 0; }
kubectl auth can-i list pods >/dev/null 2>&1 || { echo "SKIP: no API access"; exit 0; }
echo "[identity]"; kubectl config current-context; kubectl auth can-i --list
echo "[cluster-admin holders]"
kubectl get clusterrolebindings -o json | jq -r '.items[]|select(.roleRef.name=="cluster-admin")|.metadata.name+" -> "+([.subjects[]?."name"]|join(","))'
echo "[wildcard rules in user ClusterRoles]"
kubectl get clusterroles -o json | jq -r '.items[]|select((.metadata.name|startswith("system:")|not) and any(.rules[]?;((.verbs//[])|index("*")) or ((.resources//[])|index("*"))))|.metadata.name'
echo "[anonymous/unauthenticated bindings]"
kubectl get clusterrolebindings,rolebindings -A -o json | jq -r '..|objects|select(.subjects?)|select(any(.subjects[]?;."name"=="system:unauthenticated" or ."name"=="system:anonymous"))|"\(.kind // "b") \(.metadata.namespace // "-")/\(.metadata.name)"'
echo "[privileged containers in user namespaces]"
kubectl get pods -A -o json | jq -r '.items[]|select(.metadata.namespace|startswith("kube-")|not)|.metadata.namespace+"/"+.metadata.name as $p|(.spec.containers+.spec.initContainers? // [])[]|select(.securityContext.privileged==true)|$p+" ctr="+.name'
echo "[hostPath mounts]"
kubectl get pods -A -o json | jq -r '.items[]|.metadata.namespace+"/"+.metadata.name as $p|.spec.volumes[]?|select(.hostPath)|$p+" -> "+.hostPath.path'
echo "[netpol count per namespace (want default-deny in each user ns)]"
for ns in $(kubectl get ns -o jsonpath='{range .items[*]}{.metadata.name}{" "}{end}'); do printf '%-30s %s\n' "$ns" "$(kubectl get networkpolicies -n "$ns" -o name 2>/dev/null | wc -l)"; done
echo "[PSA enforce labels]"; kubectl get ns --show-labels | grep -E 'pod-security.kubernetes.io/enforce' || echo "NONE FOUND"
echo "[NodePort/LoadBalancer services]"; kubectl get svc -A | awk 'NR==1||/NodePort|LoadBalancer/'

Where To Look

Evidence collection: tools/sweeps/sweep-k8s.sh captures [K8S-nn] sections verbatim; judge them against this module's rubrics, never against raw output alone.

Assessment tooling mentions (presence = maturity signal, absence = informational):

• kube-bench — CIS Kubernetes Benchmark scans of control-plane and node hardening posture.
• kubesec — static risk scoring of workload manifests.
• OPA Gatekeeper / Kyverno — admission-time policy engines (which policies actually enforce matters more than installation).
• falco / tetragon — runtime drift detection versus declared workload behavior.
• Harbor-style registry hardening — image scanning/signing/quota controls at the registry layer.
• Distroless base images — minimal runtime surface for containerized workloads.
• etcd security assessment pointer — client/peer TLS, authn/authz flags, secret encryption-at-rest (control-plane static-pod row above).

Patterns & Signatures

Run the ripgrep battery from a repository root. All read-only.

# --- manifest-repo signature battery ---
rg -n --glob '*.{yaml,yml}' 'privileged:\s*true' .                       # instant High
rg -n --pcre2 --glob '*.{yaml,yml}' 'allowPrivilegeEscalation:\s*(?!false)' .
rg -n --glob '*.{yaml,yml}' 'hostPath:' .                                # inspect every hit
rg -n --glob '*.{yaml,yml}' 'path:\s*(/|/var/run/docker\.sock|/var/run/containerd/containerd\.sock|/proc(/sys)?|/sys|/var/lib/kubelet)' .   # Critical patterns
rg -n --glob '*.{yaml,yml}' 'host(Network|PID|IPC):\s*true' .
rg -n --glob '*.{yaml,yml}' 'hostPorts?:' .
rg -n --glob '*.{yaml,yml}' 'automountServiceAccountToken:\s*true' .
rg -l --glob '*.{yaml,yml}' 'serviceAccountName:' .                      # then read each file: automount false present?
rg -n --glob '*.{yaml,yml}' 'verbs:.*"\*"|resources:.*"\*"|apiGroups:.*"\*"' .   # wildcard RBAC
rg -l --glob '*.{yaml,yml}' 'kind:\s*(ClusterRole|Role)\s*$' .           # feed this list into the wildcard grep
rg -n --glob '*.{yaml,yml}' 'type:\s*NodePort' .
rg -n --glob '*.{yaml,yml}' 'namespace:\s*default\b' .                   # workloads in default ns
rg -c --glob '*.{yaml,yml}' 'kind:\s*NetworkPolicy' .                    # zero per user-ns dir = no default-deny evidence
rg -n --glob '*.{yaml,yml}' 'pod-security\.kubernetes\.io/enforce' .     # PSA labels in Git
rg -n --glob '**/values*.{yaml,yml}' 'privileged|hostPath|NodePort' .    # Helm override files

Helm coverage note: chart defaults often live in values.yaml while the risky decision sits in an environment override (values-prod.yaml, --set flags in CI). Grep the whole chart tree, then render with the production values and re-grep the output — that is the artifact that ships.

YAML pairs — vulnerable form, then fixed form:

# VULNERABLE — app identity holds full administrative power cluster-wide
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: payments-api
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

# FIXED — namespaced Role, named resources, read-only verbs
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: payments-api
  namespace: payments
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["payments-api-config"]
  verbs: ["get", "watch"]
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["payments-api-db"]
  verbs: ["get"]

# VULNERABLE — token mounted although the app never calls the API;
# container privileged; host runtime socket exposed
spec:
  containers:
  - name: worker
    image: registry.example.com/worker:latest
    securityContext:
      privileged: true
    volumeMounts:
    - name: dockersock
      mountPath: /var/run/docker.sock
  volumes:
  - name: dockersock
    hostPath:
      path: /var/run/docker.sock

# FIXED — no token, no privileges, no host mounts
spec:
  automountServiceAccountToken: false
  containers:
  - name: worker
    image: registry.example.com/worker@sha256:7a4f1c...  # pin immutable digest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

# VULNERABLE — bypasses ingress TLS/policy tier
apiVersion: v1
kind: Service
metadata:
  name: payments-api
spec:
  type: NodePort

# FIXED — ClusterIP behind the ingress controller
apiVersion: v1
kind: Service
metadata:
  name: payments-api
spec:
  type: ClusterIP

Taint Tracing Guidance

Treat each finding as a taint source and trace it forward (what can this identity reach?) and backward (who can touch this sink?). Report chains as one compound finding scored at its terminal sink.

Method:

1. On every High/Critical workload or RBAC finding, run the self-inspection technique as mapped onto the affected identity: read its RoleBindings and dump the referenced roles.
2. Walk escalation edges (primitives catalog above) to a fixpoint: which identities can mint/impersonate/bind to whom?
3. Record the chain explicitly ("pod X in ns payments reaches cluster-admin in two steps via token-request primitive") — this is what makes remediation prioritizable.

Exploitation & Reproduction

Everything in this section is read-only demonstration and static reasoning. No exploitation is performed against live clusters; chains are proven by reading configuration, which is sufficient evidence.

1. Self-audit interpretation guide: kubectl auth can-i --list

This is THE canonical self-inspection technique — it asks the API server to evaluate the current kubeconfig identity's effective rules, including group memberships and any ClusterRoleBindings you cannot enumerate directly. Run it first on every engagement:

kubectl auth can-i --list

Example output for a dangerously over-privileged deployer identity:

Resources                                       Non-Resource URLs   Resource Names   Verbs
*.*                                             []                  []               [*]
                                                [*]                 []               [*]
selfsubjectaccessreviews.authorization.k8s.io   []                  []               [create]
selfsubjectrulesreviews.authorization.k8s.io    []                  []               [create]

Read rows like this:

• *.* with verbs [*] — cluster-admin-equivalent. Every Secret, every pod, every node. Score the whole engagement through this lens; report as Critical if bound to anything other than break-glass humans.
• A Resources cell of roles, clusterroles, rolebindings, clusterrolebindings combined with verbs containing escalate or bind — can promote itself to any existing role. Escalation primitive.
• serviceaccounts plus serviceaccounts/token with create — TokenRequest minting chain (below).
• users, groups, serviceaccounts with impersonate — act as anyone via impersonation headers.
• pods/pods/exec with create — schedule or enter workloads to harvest their mounted tokens.
• secrets with get/list — direct credential theft within scope.
• The trailing Non-Resource URLs column showing [*] — unrestricted access to API paths (health, metrics, logs endpoints).
• Every row absent except selfsubject* review verbs — least privilege as intended; spot-check one expected verb positively (kubectl auth can-i get secrets -n payments) because an empty list can also mean a misconfigured kubeconfig rather than a hardened one.

Targeted single-question form, useful when checking a specific escalation edge:

kubectl auth can-i create serviceaccounts/token -n payments
kubectl auth can-i bind clusterrolebindings -n kube-system
kubectl auth can-i impersonate users

Note honestly in the report: answering these for another identity requires --as=system:serviceaccount:<ns>:<name> and the impersonate verb; without it, derive other identities' rights by reading Role/RoleBinding objects instead.

2. Pod-exec → same-node token theft: static verification narrative

Scenario verified purely from configuration reads:

1. Namespace payments runs two workloads. Deployment worker uses ServiceAccount payments-worker; a ClusterRoleBinding grants that SA create pods/exec cluster-wide "for debugging". Deployment api runs as SA payments-deployer, whose Role includes broad write rights.
2. Both Deployments omit automountServiceAccountToken — so both default to true and carry live tokens at /var/run/secrets/kubernetes.io/serviceaccount/token.
3. Chain, stated statically: anyone who can exec into worker reads its token → uses it to exec into api → reads the stronger payments-deployer token → operates with deployer rights. Same node not even required; network-flat design makes cross-node identical.
4. Verification commands used during audit — all reads:

kubectl get deploy -n payments worker api \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.template.spec.serviceAccountName}{"\t"}{.spec.template.spec.automountServiceAccountToken}{"\n"}{end}'
# empty third column = automount defaults ON = token present

kubectl get clusterrolebindings,rolebindings -A -o wide | grep -E 'payments-worker|payments-deployer'
kubectl get clusterrole <referenced-role> -o yaml | grep -E '^  resources:|^  verbs:' 

5. Report wording: "Exec-to-token-theft chain exists between worker→deployer identities; verified via automount default and RBAC rule inspection. No exec was performed." Severity follows the terminal sink per Taint Tracing.

3. Manifest-repo vulnerable→fixed diffs

 # roles/payments-api.yaml
 rules:
-- apiGroups: ["*"]
-  resources: ["*"]
-  verbs: ["*"]            # VULNERABLE
+- apiGroups: [""]
+  resources: ["configmaps", "secrets"]
+  resourceNames: ["payments-api-config", "payments-api-db"]
+  verbs: ["get", "watch"]  # FIXED: named resources, read-only

 # deploy/payments-worker.yaml
 spec:
   template:
     spec:
+      automountServiceAccountToken: false   # FIXED: app never calls the API
       containers:
       - name: worker
         securityContext:
-          privileged: true                  # VULNERABLE
+          allowPrivilegeEscalation: false   # FIXED
+          readOnlyRootFilesystem: true
+          capabilities:
+            drop: ["ALL"]

 # svc/payments-api.yaml
 spec:
-  type: NodePort        # VULNERABLE: bypasses ingress tier
+  type: ClusterIP       # FIXED: served via ingress w/ TLS termination

Remediation

Apply inside an approved change window; all blocks below are the target state.

Hardened workload template

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments-api
  namespace: payments
spec:
  replicas: 2
  selector:
    matchLabels: { app: payments-api }
  template:
    metadata:
      labels: { app: payments-api }
    spec:
      serviceAccountName: payments-api
      automountServiceAccountToken: false          # no API identity unless required
      securityContext:                             # pod-level
        runAsNonRoot: true
        runAsUser: 10001
        runAsGroup: 10001
        fsGroup: 10001
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: api
        image: registry.example.com/payments-api:v1.4.2   # prefer immutable sha256 digest pinning
        securityContext:                           # container-level
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          capabilities:
            drop: ["ALL"]
        resources:
          requests: { cpu: 100m, memory: 128Mi }
          limits:   { cpu: "1",  memory: 512Mi }
        volumeMounts:
        - name: tmp
          mountPath: /tmp
      volumes:
      - name: tmp
        emptyDir: {}

If the workload must call the Kubernetes API, keep automounting but scope its Role to the minimum verbs/resources shown below — never leave it defaulted AND unscoped.

Default-deny NetworkPolicy pair with DNS exception

# FIXED: deny-by-default for the namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]
---
# FIXED: carve out DNS BEFORE enabling egress denial, or everything breaks
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-dns
  namespace: payments
spec:
  podSelector: {}
  policyTypes: ["Egress"]
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns     # verify the real selector: kubectl get svc -n kube-system kube-dns -o yaml
    ports:
    - { protocol: UDP, port: 53 }
    - { protocol: TCP, port: 53 }

Add per-application allow policies after DNS; stage egress denial per namespace, never fleet-wide at once (see the staged approach in the firewall-edge module philosophy).

Least-privilege RBAC for a typical app SA

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: payments-api-app
  namespace: payments
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["payments-api-config"]
  verbs: ["get", "watch"]
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["payments-api-db"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: payments-api-app
  namespace: payments
subjects:
- kind: ServiceAccount
  name: payments-api
  namespace: payments
roleRef:
  kind: Role
  name: payments-api-app
  apiGroup: rbac.authorization.k8s.io

Rules of thumb while rewriting RBAC: namespaced Role over ClusterRole whenever possible; resourceNames where the API allows it; strip escalate, bind, impersonate, serviceaccounts/token, pods/exec from every workload identity; reduce human cluster-admin holders to a documented break-glass list.

Namespace PodSecurity labels

apiVersion: v1
kind: Namespace
metadata:
  name: payments
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest   # pin a minor version in production for upgrade stability
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: latest

Stage rollout: apply warn first, collect violations for one release cycle, fix manifests, then set enforce. Policy engines (Kyverno, Gatekeeper) are the established options once built-in PodSecurity ceilings are hit — evaluate them qualitatively against org requirements before adopting either.

Kubelet / node items (pointers)

Set kubelet authorization.mode: Webhook and readOnlyPort: 0 in /var/lib/kubelet/config.yaml on every node; treat any AlwaysAllow or open 10255 as High. Node SSH/OS baseline, runtime socket permissions, and patch level are owned by the linux-baseline module — hand off rather than duplicating checks here.

Verification & Validation

Post-fix sweeps must come back clean

Re-run the full read-only sweep block and the repo battery. Expected clean state:

• kubectl auth can-i --list for every workload identity shows only intended rows; no *.*, no escalation primitives.
• Wildcard grep returns only built-in system: roles; zero user-created wildcard rules.
• Zero privileged containers and zero hostPath volumes in user namespaces.
• Every user namespace shows ≥1 default-deny NetworkPolicy with both policyTypes, plus the DNS exception policy where egress is denied.
• kubectl get ns --show-labels shows PSA enforce labels on all user namespaces.
• NodePort listing is empty or matches the documented exception list.

Functional verification (change window only — these commands mutate)

Positive/negative pair after enabling default-deny:

# POSITIVE control: DNS still resolves (the classic regression)
kubectl run netcheck --rm -it --restart=Never --image=busybox:1.36 -n payments \
  -- nslookup kubernetes.default.svc.cluster.local

# NEGATIVE test: cross-namespace access now blocked
kubectl run probe --rm -it --restart=Never --image=busybox:1.36 -n payments \
  -- wget -qO- --timeout=3 http://<service>.<other-ns>.svc.cluster.local || echo "BLOCKED (expected)"

# APP serves: deploy and hit the route end-to-end
kubectl rollout status deploy/payments-api -n payments
curl -fsS https://payments.example.com/healthz

An application that deploys, resolves DNS, and serves through ingress while cross-namespace probes fail is the pass condition. A broken DNS lookup means the egress policy lacks the UDP/TCP 53 carve-out — fix before proceeding.

Regression watchlist

IaC greps post-fix

# All four must return nothing outside the documented-exceptions file
rg -n --glob '*.{yaml,yml}' 'privileged:\s*true' . | rg -v exceptions.yaml
rg -n --glob '*.{yaml,yml}' 'hostPath:' . | rg -v exceptions.yaml
rg -n --glob '*.{yaml,yml}' 'type:\s*NodePort' . | rg -v exceptions.yaml
rg -n --glob '*.{yaml,yml}' 'verbs:.*"\*"|resources:.*"\*"' . | rg -v system-roles/
# And this must return hits for every user namespace directory:
rg -c --glob '*.{yaml,yml}' 'kind:\s*NetworkPolicy' .

Severity Assessment

Score chains at their terminal sink. Vectors are illustrative CVSS v3.1 base anchors for triage consistency — adjust scope/privilege metrics to the environment before quoting numbers.

Cluster-admin blast radius framing — state this in every report: a single cluster-admin binding converts any foothold into total compromise of everything the cluster touches. It yields read access to all Secrets (defeating every upstream control), exec into every pod, privileged DaemonSets on every node (converting to host-fleet compromise), and persistent API objects that survive pod cleanup. When counting holders, treat each additional human beyond the break-glass list as High, each workload SA as Critical, and justify every platform identity in writing.

Common False Positives

• System namespaces are legitimately privileged. kube-system, kube-public, kube-node-lease and platform namespaces (ingress controller, CNI, monitoring) run privileged containers, hostNetwork, and hostPath by design. Scope workload sweeps to user namespaces and maintain an explicit platform allowlist instead of reporting these as findings.
• Built-in roles contain wildcards on purpose. cluster-admin and system:* ClusterRoles legitimately hold *. Audit bindings and user-created roles — the existence of built-in wildcard roles is not a finding.
• Managed control planes hide their config. On GKE/EKS/AKS there are no static-pod manifests and no EncryptionConfiguration file visible to you. Absence of evidence is not misconfiguration: audit what your identity can see (RBAC, workloads, netpols), verify provider-managed features via provider documentation/console, and record the visibility limitation in the report.
• Dev/staging clusters run relaxed posture legitimately. Findings remain real but severity is contextual; document the environment boundary explicitly so relaxed dev baselines never normalize into production reviews.
• A NetworkPolicy present ≠ default-deny. A policy with a narrow podSelector or missing policyTypes: Egress leaves most traffic untouched. Verify shape (podSelector: {} + both policyTypes) before crediting coverage.
• PSA warn/audit labels are advisory only. Without the enforce label nothing is blocked; report warn-only namespaces as Medium, not compliant.
• Helm values files mislead. Chart defaults get overridden per environment; only rendered output (helm template -f values-prod.yaml) shows what ships.
• Missing runAsNonRoot may still run non-root. An image with a non-root USER directive works today but regresses silently on image swap — still record it as hardening debt, not as an active privilege finding.

References

• Kubernetes documentation root — https://kubernetes.io/docs/home/
• Using RBAC Authorization (defines verbs incl. escalate/bind/impersonate semantics) — https://kubernetes.io/docs/reference/access-authn-authz/rbac/
• Pod Security Standards — https://kubernetes.io/docs/concepts/security/pod-security-standards/
• Pod Security Admission (label keys and modes) — https://kubernetes.io/docs/concepts/security/pod-security-admission/
• Configure Service Accounts for Pods (automountServiceAccountToken) — https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/
• Encrypting Secret Data at Rest (EncryptionConfiguration) — https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
• Network Policies — https://kubernetes.io/docs/concepts/services-networking/network-policies/
• kube-apiserver command-line reference (man-page equivalent: flags incl. anonymous-auth, audit-policy-file, encryption-provider-config) — https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/
• kubelet config reference (man-page equivalent: authorization mode, readOnlyPort) — https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/
• kubectl Command Reference (man-page equivalent: auth can-i, create token) — https://kubernetes.io/docs/reference/kubectl/
• CIS Kubernetes Benchmark (Center for Internet Security) — https://www.cisecurity.org/benchmark/kubernetes
• NSA & CISA, "Kubernetes Hardening Guidance" (v1.1, August 2022; original August 2021) — https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETESHARDENINGGUIDANCE.PDF