Why is AVD-KSV-0050 listed as a critical?

[james-mchugh]

IDs

AVD-KSV-0050

Description

The description of AVD-KSV-0050 appears to indicate that the mere presence of roles or rolebinding permissions in a role is enough to escalate privileges. However, this is not the case. The Kubernetes API prevents roles from being created with more roles than the authorizer unless the authorizer already has escalate permissions. Similarly, a role can not be bound to a service account that unless the authorizer has the requested roles or has explicit bind permissions for the role.

Why does Trivy flag the presence of any role/rolebinding permisisons as critical instead of directly flagging uses of escalate, bind, or impersonate? What's even more interesting is that usage of escalate in verbs is not flagged any differently than other operations, even though that would be a true cause for concern security-wise.

I understand it may generally be a good practice to avoid dynamically provisioning roles or rolebindings, such as in an operator for example. However, it seems overkill to list it as a critical issue that can lead to privilege escalation.

Am I missing another concern here around CRUD access to roles/rolebindings?

Thank you!

Reproduction Steps

1. Create a Helm chart with a role that includes create, update, patch, or delete permissions for roles or rolebindings.
2. Scan the chart using `trivy config <path-to-chart>`
3. Observe critical AVD-KSV-0050 finding for role.

Target

Filesystem

Scanner

Misconfiguration

Target OS

No response

Debug Output

NA

Version

0.66.0

Checklist

• Read the documentation regarding wrong detection
• Ran Trivy with -f json that shows data sources and confirmed that the security advisory in data sources was correct

[nikpivkin]

Hi @james-mchugh !

Thank you for the detailed explanation. You are absolutely correct: the Kubernetes API server will not allow creating or binding roles with privileges exceeding those of the current subject without escalate or bind. This behavior is documented here:

• Restrictions on role creation or update:
  https://kubernetes.io/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update
• RBAC good practices:
  https://kubernetes.io/docs/concepts/security/rbac-good-practices/

Currently, the Trivy rule marks any write access to roles and rolebindings as CRITICAL, because it is based on conservative hardening guidelines and on real-world scenarios where cluster authorization may not be strictly enforced. In such environments, the ability to create or modify RBAC objects can often lead to privilege escalation in practice.

However, from a technical perspective, it would be more accurate to differentiate the cases:

• escalate, bind, and impersonate are truly critical, as they directly allow privilege escalation
• regular verbs (create, update, delete) on roles or rolebindings are less severe in clusters where authorization is properly configured

This is a good suggestion for improving the rule, and we can update it to reduce false positives.

cc: @afdesk @simar7

[james-mchugh]

That makes sense. Thank you for the detailed explanation! I think your proposed changes make sense, and would be a great improvement!

[simar7]

Track #9826