search

PaloAltoNetworks / rbac-police

Evaluate the RBAC permissions of Kubernetes identities through policies written in Rego
https://www.paloaltonetworks.com/resources/whitepapers/kubernetes-privilege-escalation-excessive-permissions-in-popular-platforms
MIT License
339 stars 35 forks source link

Question for issue_token_secrets and list_secret policies #17

Open UgOrange opened 1 year ago

UgOrange commented 1 year ago

Documentation link

link

Describe the problem

I am currently studying your detection rules and have come across a couple of questions that I would appreciate your assistance with. Regarding the "issue_token_secrets" rule, it appears to detect permissions related to modifying or creating secrets. I would like to understand how this rule handles the issuance of administrator-equivalent service account privileges. Additionally, I believe that the risk level associated with the "list_secret" rule could be increased. I would like to suggest considering an adjustment to reflect a higher level of risk.

Suggested fix

welcome-to-palo-alto-networks[bot] commented 1 year ago

:tada: Thanks for opening your first issue here! Welcome to the community!

yuvalavra commented 1 year ago

Hi, good question! If you can create a secret you can link it to a service account (using a few fields in the secret definition) and Kubernetes will automatically populate a new token for that SA in the secret :) At that point if you can somehow read the secret you could retrieve that token and potentially escalate privileges depending on its permissions.

Btw at the bottom of the report linked in this repo description there are explanations for how the permissions in most of the policies lead to attacks.

As for the severity of secrets listing policy - I agree, could be changed to High.