Ensure access to Secrets is minimized and granted only where required

How it is checked

Audit method: Manual review

This recommendation cannot be checked automatically. A scan lists it with these instructions when you pass --include-manual.

Review the users, groups, and service accounts that have get, list, or watch access to Secret objects in the Kubernetes API. Identify these permissions in Kubernetes Role and ClusterRole rules, then trace the associated RoleBinding and ClusterRoleBinding objects to the affected identities. Because Microsoft Entra ID authorization for the Kubernetes API is preconfigured in AKS Automatic, also review Azure role assignments to users, groups, service principals, and managed identities that allow access to Secrets.

How it is fixed

Fix method: Guidance or infrastructure patch

Where access is not required, remove get, list, and watch access to Secret objects in the cluster. For Kubernetes RBAC, remove the unnecessary verbs from the applicable Role or ClusterRole, or remove the binding that grants the role to the identity. For Microsoft Entra ID authorization, replace broad assignments with a role that does not permit Secret access, such as Azure Kubernetes Service RBAC Reader when read access to other resources is sufficient. Confirm that workloads, controllers, and administrative processes continue to function with the replacement permissions before removing the existing access.