aegis-kubernetes-cluster-hardening

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.