auditing-kubernetes-workload-and-rbac-hardeninglisted

# Auditing Kubernetes workload and RBAC hardening: what the binding graph and admission actually allow A wildcard ClusterRole that nothing binds grants nobody anything, and a privileged pod that admission rejects never deploys. That is why this audit is not a scan of role verbs and pod fields; it is a resolution of the binding graph (which subject is actually granted a role) and the admission layer (whether the workload can deploy as written). The competitors flag a wildcard role or a root container in isolation; the finding that survives is the one where a binding grants the power to a workload that can use it, and admission does not stop it. You audit the manifests by resolving those two layers and asking, per subject and per workload, whether it holds more than it needs and can act on it. Stay on the Kubernetes YAML plane, not the cloud IAM graph and not the image build. ## When to use - You have Kubernetes manifests: roles and bindings, pod and workload specs, service accounts, network policies. - A binding references cluster-admin or a wildcard role, or a pod sets a privileged or host-level security context. - You want to know which grants and privileges the binding graph and admission actually allow, not which appear. ## Scope check Audit only manifests for clusters you own or are authorized to assess, and never apply a manifest or exercise a binding against a live cluster to test a finding, adjudicate on the resolved graph. If you can't name the authorization, sto