How to Perform a Kubernetes Security Audit for Misconfigured RBAC

Kubernetes role-based access control (RBAC) determines which users, groups and workloads can call the Kubernetes API. Misconfigured policies can let a compromised application read secrets, run privileged pods or cross namespace boundaries. A Kubernetes security audit for misconfigured RBAC policies must test both declared permissions and the escalation paths they create.

For Australian teams, findings should align with the Australian Signals Directorate’s Essential Eight and, where relevant, the Information Security Manual, APRA CPS 230, or OAIC guidance under the Privacy Act 1988. This evidence can support boards, regulators and procurement teams, but compliance does not replace technical validation.

Set the audit scope and local obligations

Start with scope and evidence. Identify production, development and CI clusters, self-managed control planes, and managed AWS, Azure or Google Cloud offerings. Record API versions, admission controllers, namespace ownership and business criticality. Managed clusters reduce control-plane duties, but do not remove the need to review Kubernetes RBAC, workload identities and cloud IAM links.

Build a cluster register by owner, environment and sensitivity, including Australian cloud regions supporting Sydney, Melbourne and Brisbane operations. Note federated identities and data flows. Canberra-based agencies with customs or border responsibilities may also need the Information Security Manual, while APRA-regulated finance teams should map RBAC evidence to CPS 230. Healthcare and e-commerce operators should consider OAIC expectations and the Privacy Act.

Build a complete RBAC inventory

Export and compare ClusterRoles, ClusterRoleBindings, Roles and RoleBindings, including operator defaults. Compare live API objects with GitOps or Helm-managed source. Flag wildcard apiGroups, resources or verbs, broad ClusterRoleBindings, bindings to system:authenticated or system:unauthenticated, and permissions for secrets, pods/exec, pods/portforward and workload creation.

Trace every subject to human SSO groups, external directories, CI identities and service accounts. Remove stale accounts and orphaned bindings. Privileged verbs such as create on rolebindings, escalate, bind and impersonate deserve scrutiny because they can turn modest access into cluster-wide control. Check built-in and aggregated roles rather than assuming their names reflect safe defaults.

Test authorisation and privilege escalation

Translate the YAML review into effective authorisation. Use kubectl auth can-i --list --as=... for representative users and service accounts, then test specific actions against namespaces and resources. Include denied-by-default cases for unauthenticated access and low-privilege pods. This reveals permissions created by group membership, missing resourceNames or role aggregation that a static role review can miss.

Exercise safe escalation paths in an approved window or test cluster: try to read secrets, exec into pods, mount service-account tokens, create an elevated workload, bind a stronger role, or impersonate another identity. Work from a compromised workload perspective and record the shortest path to a sensitive action. Avoid destructive actions in production.

Review workload identity and cloud trust

Review service-account hygiene. Find automatic token mounting, long-lived legacy tokens, shared accounts and secrets embedded in deployment manifests. Use dedicated identities for each workload, disable automount where Kubernetes API access is unnecessary, and prefer short-lived projected tokens. Check whether application code receives broader API permissions than its function requires.

Connect Kubernetes trust to cloud IAM. For Amazon EKS, Azure Kubernetes Service and Google Kubernetes Engine, inspect IRSA, workload identity federation or managed-identity mappings for wildcard cloud roles and cross-account trust. A namespace restriction cannot compensate for a workload identity that can administer a production account. Check node access, CI runners, secrets stores and federation with unmanaged identities.

Verify logging and detection coverage

Verify that Kubernetes audit logs capture RBAC-relevant events, including changes to roles and bindings, secret access, pod exec, impersonation and workload creation. Check the audit policy on self-managed control planes and equivalent logging configuration in managed services. Application logs alone are insufficient because they may never record rejected or successful API requests.

Define alerts and evidence controls in the SIEM. Detect new ClusterRoleBindings, changes to privileged verbs, dormant-account access and bursts of secret reads. Include requester, target, namespace, source IP and correlation identifiers, while protecting sensitive payloads. Align retention and time synchronisation with incident-response and regulatory evidence needs.

Apply layered remediation controls

Prioritise findings by reachable impact rather than YAML volume. A wildcard secret read in a production namespace may outrank a noisy low-risk cluster role. Record exploitability, affected namespaces, business ownership, compensating controls and a remediation deadline, then have the cluster owner validate each proposed change.

• Replace wildcard apiGroups, resources and verbs with the narrowest required actions; remove unused escalate, bind and impersonate.
• Prefer namespace-scoped Roles and specific resourceNames; reserve ClusterRoles and ClusterRoleBindings for demonstrably shared privileges.
• Remove broad grants to system:authenticated and system:unauthenticated, and recertify human and service-account bindings regularly.
• Disable unnecessary service-account token mounting, rotate legacy credentials and bind workloads to least-privilege cloud identities.
• Enforce policy in CI with schema, policy-as-code and admission controls, then monitor exceptions and changes through the SIEM.

Stage high-risk changes through tested pull requests, preserve an auditable rollback plan, and monitor the cluster after deployment. Where Kubernetes objects are generated by Helm or Flux, update the source template and rendered manifest together so drift does not recreate the weakness.

Retest and sustain continuous assurance

Retest after remediation using the same identities and attack paths, with success measured by both blocked privilege and preserved application access. Add the checks to CI/CD and scheduled reviews, and track exceptions through risk acceptance. Kubernetes RBAC changes can be subtle: one broad binding may reopen an old path even when the original role was tightened.

Infoziant Security supports vulnerability assessment and penetration testing, managed security, infrastructure and cloud audits, SIEM monitoring, threat intelligence and compliance assistance for Australian enterprises, government, finance, e-commerce and healthcare organisations. Review the available free VAPT reports, then start a trial-based engagement to establish a verified RBAC baseline and prioritise remediation.