This is a core  capability that was suggested by Chris Porter a long time ago. It is mostly  Build/Deploy stage but may have runtime capabilities as well

While this topic can be covered using VAP and Kyverno, I believe this is an area that we should address directly. We currently scratch the surface and it would add significant value.

It would be a major, innovative addition to ACS policy which requires exploration. We may need a couple of brainstorming sessions to capture the right scope and carve out an MVP.  Here are some thoughts to get us started:

• Revise policy criteria section in the UI to consolidate all RBAC issues (currently we only have service account checks)
• Add default policies that align with recommended best practices
• Research: which resources (cluster + NS) do we need to review
• Research: what should the criteria UX be? Specifically can we understand  RBAC elements at a higher level and relate to them?
• What are some useful cross checks (combined criteria) for recommended default policies 
• How should these criteria impact the Risk module ?
• What are the internal ACS security guardrails for checking RBAC rules ? (make sure we don't expose a privileged query to a non privileged ACS role) 
• What can we do with AI ?
• What are the related compliance controls which we can satisfy ? 
• Runtime: Chris suggested actual (audit log) usage of verbs and resources for a given user. Explore this further
• Study the reference that Chris provided https://github.com/liggitt/audit2rbac?tab=readme-ov-file 

Use Case:

From a security perspective, I would like to know when my users, groups, service accounts have access to Kubernetes verbs and resources that I don't need. Excess permissions for access to objects allows users or an attacker to disregard security rules and access sensitive Kubernetes objects.

Context

ACS currently has visibility into Kube RBAC - Users, Groups, Roles, ClusterRoles, RoleBindings, ClusterRoleBindings, and can show all details of allowed API verbs, resources, etc

ACS currently has deploy policy criteria for Service Accounts and elevated permissions for SAs, and runtime policy for API verbs on named resources.

Proposal is to extend the current featureset to include recommendations for proper RBAC, and warnings of over-privileged users, based on actual (audit log) usage of verbs and resources for a given user.

(this project has an example of what's possible: https://github.com/liggitt/audit2rbac)