Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Evaluating switching to Capsule ProxySetting rather than using RoleBindingReflector #268

Open
prometherion opened this issue Mar 7, 2023 · 1 comment

Comments

@prometherion
Copy link
Member

Starting the discussion from #266 (comment) thanks to @MaxFedotov:

I remember why I added this feature. The idea was the following:

  • Tenant admin create a role and rolebinding in one of his namespaces for user Bob. This role has a limited set of permissions (it is not cluster-admin)
  • Bob must be able to see all namespaces, where he has access when running kubectl get ns

This reflector caches all rolebindings and is used for getting a list of namespaces to be shown for each of the users.
And as reflectors are asynchronous by default, this can add a delay between kubectl create ns and kubectl get ns

Now capsule-proxy adds new ProxySetting CRD, which can be used to add permissions for both, tenant admins and normal users. But removing this reflector would require tenant admins to create a separate ProxySetting CRD for each of the users rolebindings in all namespaces.

My thoughts: we could create a specific addon that replicates the ProxySetting resources for each ServiceAccounts that has GET permission on its Namespace, in order to let them list Namespace as would happen for a regular user.

Not sure if this would be the duty of capsule-proxy here, but I'd like to get feedback from end-users and adopters.

@MaxFedotov
Copy link
Collaborator

From one side I like the idea of moving to ProxySetting, as it can be seen as a natural capsule way.

But on the other side, I don't like the idea of breaking the current design (and being not backward-incompatible), which can be already used by the community (and yes, it is already used by us :) ) and will require them to perform additional activities during and update and afterward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants