Kubernetes RBAC Security Audit Report

Cluster: [prod-aks-cluster]

Date: 2026-03-17
Scope: All ClusterRoleBindings & RoleBindings
Prepared for: Access Review

This audit reviewed 107 RBAC grants across a production AKS cluster and resolved all principals against Azure Active Directory. The review identified 46 findings across 32 CRITICAL and 12 HIGH issues. The most significant concerns are two CI/CD service accounts with broad cluster access whose Azure managed identities cannot be verified, a built-in Kubernetes ClusterRole that has been tampered with to include privilege escalation capabilities, and an account from an unrecognised external domain that holds namespace admin access.

107
RBAC Grants
32
Critical
12
High
46
Total Findings

Executive Summary

#SeverityIssueAction
1criticalCI/CD Pipeline SA Has Cluster-Admin; Managed Identity BrokenInvestigate
2criticalGitHub Actions Deploy SA Has Near-Cluster-Admin; Identity BrokenInvestigate
3criticalBuilt-in `edit` ClusterRole Has Been Tampered WithRevoke
4criticalApplication Service Account Has Cluster-AdminRevoke
5criticalExternal Domain User Has Namespace Admin; Not Found in DirectoryRevoke
6criticalCloud-Engineering Group Holds cluster-adminReview
7criticalDevOps Group Holds Admin Cluster-Wide with Escalation CapabilitiesReview
8highDangerous Unbound ClusterRole with Wildcard PermissionsRevoke
9highCloud-Engineering Has Duplicate Access Path via Azure RBACReview
10highDevOps Has Duplicate Access Path via Azure RBACReview
11highDevelopers-Payments Has Debug Access to the Analytics NamespaceReview
12highDevelopers-Analytics Has Duplicate Azure RBAC Access PathReview
13highSales Group Has Duplicate Azure RBAC Access Path (Broader Scope)Review
14mediumTwo Users Reach the Cluster Through Two Group MembershipsReview

1. Identity Issues

2. Permission Issues

3. Access Review Items

Groups — click to expand membership and rationale

Direct User Bindings

External domain userRevoke recommended
Access: admin — namespace: rbac-test-env
Account type: Not found in directory — external domain, not the organisation's tenant
Cannot be attributed to a known identity. Should be treated as a stale or rogue binding. See Issue 5.

AKS system identities (certificate/token auth) are listed for completeness in the Infrastructure Appendix below — not actionable for this review.

4. What Looks Good

  • No orphaned group bindings. All 6 groups resolved successfully in Entra ID — no bindings point to groups that have been deleted from the directory.
  • No guest users with cluster access. All resolved group members are internal accounts.
  • No disabled accounts with active grants. No bindings were found for deactivated accounts.
  • Group-based access is the norm. The majority of human access is managed via groups rather than direct user bindings, which is the correct pattern for auditability and bulk revocation.
  • Namespace scoping is used for developer groups. Developer group bindings are scoped to their respective namespaces rather than cluster-wide.

5. AKS Infrastructure Appendix

Expected AKS system components — not actionable for this review.

PrincipalRoleNotes
AKS control plane identitiescluster-adminCertificate auth, not Entra accounts
AKS support identityaks-serviceManaged support identity
AKS Secrets Store CSI driveraks-secretprovidersyncing-roleAKS-managed CSI driver
Azure File CSI storage drivercsi-azurefile-node-secret-roleAKS storage driver
Secrets Store rotation controllersecretproviderrotation-roleAKS secrets rotation
Calico network operatortigera-operatorAKS network policy engine
AKS monitoring agentssystem:prometheus, etc.AKS telemetry

Closing Summary

Top Priority — Issues 1 & 2

The two CI/CD service accounts with broken managed identity chains. Both are effectively unowned and unauditable. azure-devops-pipeline has full cluster-admin. Confirm with the pipeline teams, then either reconnect the identity chain with workload identity federation or delete the bindings. This is the easiest high-impact fix in the report.

Most Interesting Finding — Issue 3

The tampered edit ClusterRole. Deterministic rule-checking alone would surface this as a CIS violation, but without understanding why edit has impersonate verbs, a reviewer might dismiss it as a cluster customisation. The combination of detecting the modification, tracing it to an aggregation role, and identifying which groups are affected is where the audit adds value beyond a raw rule scan.

Quick Wins

kubectl delete clusterrolebinding app-platform-admin
kubectl delete rolebinding team-environment-admin -n rbac-test-env
kubectl delete clusterrole platform-developer

Next Steps

  1. Re-run the audit after revoking Issues 1–5 to confirm finding count drops
  2. Have group owners sign off on Issues 6–7 or scope-reduce those bindings
  3. Add group owners in Entra ID for all six access groups — currently none have designated approvers for membership changes
  4. For developer groups, evaluate replacing the built-in edit role with a custom role that excludes pods/exec and impersonation

SecureAudit AI — Kubernetes RBAC Access Review