capsule-proxy
capsule-proxy copied to clipboard
Evaluating switching to Capsule ProxySetting rather than using RoleBindingReflector
Starting the discussion from https://github.com/clastix/capsule-proxy/issues/266#issuecomment-1456226221 thanks to @MaxFedotov:
I remember why I added this feature. The idea was the following:
Tenant admincreate aroleandrolebindingin one of his namespaces for userBob. Thisrolehas a limited set of permissions (it is notcluster-admin)Bobmust be able to see allnamespaces, where he has access when runningkubectl get nsThis reflector caches all
rolebindingsand 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 betweenkubectl create nsandkubectl get nsNow capsule-proxy adds new
ProxySettingCRD, 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 separateProxySettingCRD for each of the usersrolebindingsin 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.
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.