You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current default RBAC role bindings for kanister operator allow creation of pods in any namespaces with any service accounts, thus enabling privilege escalations.
Kanister should adopt safer default, such as only allowing to create pods in the kanister namespace.
It can also document or provide tools for users to set up roles for the blueprints which require them.
Thanks for opening this issue 👍. The team will review it shortly.
If this is a bug report, make sure to include clear instructions how on to reproduce the problem with minimal reproducible examples, where possible. If this is a security report, please review our security policy as outlined in SECURITY.md.
If you haven't already, please take a moment to review our project's Code of Conduct document.
TODO: check what happens on helm chart upgrade and create upgrade instructions.
We also need to document that existing users need to downgrade permissions for kanister to only create pods in specific namespaces.
Current default RBAC role bindings for kanister operator allow creation of pods in any namespaces with any service accounts, thus enabling privilege escalations.
Kanister should adopt safer default, such as only allowing to create pods in the kanister namespace.
It can also document or provide tools for users to set up roles for the blueprints which require them.
Security advisory:
GHSA-h27c-6xm3-mcqp
The text was updated successfully, but these errors were encountered: