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
When using this proxy to expose kubernetes api to external (read: non-trusted) users a very helpful option would be to limit what API groups are exposed trough proxy. This way one can be sure that the external user is only allowed to interact with certain APIs (eg. allow interacting only Deploymens or a cusom resource but do not allow user to list Nodes for example).
Would a PR for his make sense?
The text was updated successfully, but these errors were encountered:
I've been kicking around a similar idea, so a PR would be welcome! I don't want to implement this specific use case though. I'm thinking either a webhook or a WASM "plugin"? My thought is that given a payload and user.Info I should be able to make any authorization decision I want. WDYT?
Not clear why we need to mix authentication and authorization in one tool. Why we can't deny access to some API groups via native RBAC objects in kubernets: clusterroles, roles, rolebindings?
@omelnyk1 RBAC is pretty basic in how it does authorization. You could use an admission controller too, depending on how you want to implement it. You may also want to control access based on which network admins come from, which you can't do with RBAC. It's an additional option.
When using this proxy to expose kubernetes api to external (read: non-trusted) users a very helpful option would be to limit what API groups are exposed trough proxy. This way one can be sure that the external user is only allowed to interact with certain APIs (eg. allow interacting only Deploymens or a cusom resource but do not allow user to list Nodes for example).
Would a PR for his make sense?
The text was updated successfully, but these errors were encountered: