Globally filter namespaces by blacklist/whitelist

[smerschjohann]

Summary It should be possible to filter the visible namespaces (and their included apps) through either a whitelist or blacklist (or maybe both)

Background and rationale As mentioned in #4921 and #4922, it would be nice for different use cases to allow to filter the visible list of namespaces through some label selectors. This would allow a nicer user experience and a kind of "managed by kubeapps" experience

Description If a whitelist is defined, the user should only see namespaces that match this whitelist (by label selector, by name regex) If a blackist is defined, the user should only see namespaces that do NOT match the blacklist (by label selector, by name regex)

Acceptance criteria The namespaces (and apps) are filtered by the criterias defined by the whitelist and blacklist.

[absoludity]

Interesting idea @smerschjohann . Similar to my comment on your other issue, I assume you don't mean that this would allow users to see namespaces to which they don't have RBAC, but rather, this is just a way of specifying a subset of the namespaces to which a user has access?

[smerschjohann]

Yes, kubeapps can and should not tinker with the kubernetes RBAC by for example using another service account for that user. Instead only a subset of accessible namespaces should be visible.

[asalic]

I would also like to see this feature in Kubeapps. Or, maybe, you could leave all namespaces, and add a feature to request access to a namespace, and that request could be sent to the admin. In this case, you could have a list split in two: first part with accessible namespaces, and the second part with restricted.

[smerschjohann]

@asalic I'm not sure if I understand you right, but it would be possible with e.g. following (not final!) configuration:

createNamespaceLabels:
    managed-by: kubeapps
    approval-pending: true
visibilityFilters:
   includes:
   - type: nsSelector
     value: "managed-by=kubeapps"

and your admins have to approve (somewhere) so that the user gets a RoleBinding for that namespace, and remove that aproval label. In my use case I wanted to auto approve that for new namespaces by a Kyverno generate rule.

@absoludity what do you think?

[absoludity]

I would also like to see this feature in Kubeapps. Or, maybe, you could leave all namespaces, and add a feature to request access to a namespace, and that request could be sent to the admin. In this case, you could have a list split in two: first part with accessible namespaces, and the second part with restricted.

Hi @asalic . Just to be clear: Kubeapps does not show users namespaces to which they do not have access (ie. which they cannot see), so I'm not sure how users could request access to a namespace? We're really keen not to add any privileges beyond what Kubernetes supports and make very few exceptions (the ability to be able to list the namespaces to which you have access being one of them). Either way, I reckon that is a different feature request from yours @smerschjohann , which doesn't involve extra RBAC.

@asalic I'm not sure if I understand you right, but it would be possible with e.g. following (not final!) configuration:

createNamespaceLabels:
    managed-by: kubeapps
    approval-pending: true
visibilityFilters:
   includes:
   - type: nsSelector
     value: "managed-by=kubeapps"

and your admins have to approve (somewhere) so that the user gets a RoleBinding for that namespace, and remove that aproval label. In my use case I wanted to auto approve that for new namespaces by a Kyverno generate rule.

@absoludity what do you think?

What would happen if I, as a user, create a new namespace in the Kubeapps UX? From what I understand here, the namespace would get created but with the labels you've mentioned. So I would see it via kubectl but would not see it after creating it in the UX.

I'm not 100%, but my initial thought is that I don't think Kubeapps should be involved in any approval workflow for namespaces etc. I don't see a problem with the filter and label for configuration, so that the operator can limit the namespaces presented in Kubeapps. Hope that helps!

[smerschjohann]

@absoludity Yes, as of now (in the released software), if you create new namespaces, it is not visible in Kubeapps and leads to an error message after creation. You would not see it in kubectl either as you have no permission to list all namespaces. You are basically left with a new namespace that you cannot use or see ;)
I solved it for me by a Policy-Controller that kicks in and creates the bindings for the user. But it would be nice, if it could know that the namespace was created by kubeapps in behave of the user (by adding that label).

The extra label (approval-pendining: true) was just a suggestion, how a manual process could look like: Search for namespaces with a specific label, do your approval process, remove that label. But with the little problem, that kubeapps does not know the users identity.

[absoludity]

@absoludity Yes, as of now (in the released software), if you create new namespaces, it is not visible in Kubeapps and leads to an error message after creation.

Sorry, I'm missing something here - I mean, that sounds like a bug (unless there's something special in your environment) but normally if you create a new namespace in Kubeapps you should be redirected to your new namespace (and the normal Kubeapps functionality should handle getting the list and filtering with only the ones to which you have access). I'll fix my dev env and test the situation (been a while since I've used a non-admin user, but we do have CI checks for it, though perhaps not for namespace creation - we should add that).

You would not see it in kubectl either as you have no permission to list all namespaces. You are basically left with a new namespace that you cannot use or see ;)

That shouldn't be the case: you should be able to use the namespace without issue - you don't need to be able to list all namespaces to use a namespace that has been created.

I solved it for me by a Policy-Controller that kicks in and creates the bindings for the user. But it would be nice, if it could know that the namespace was created by kubeapps in behave of the user (by adding that label).

Can you describe more about the policy controller setup that you have? Just so when I'm reproducing I know whether some things may be specific to your env or not. I'll repro tomorrow and update then.

Thanks for all the info!

[smerschjohann]

@absoludity I won't say that it is a bug, if you create a namespace in kubernetes using "kubectl create namespace XYZ", you will create that resource. Something must create the RoleBinding for that new namespace for you. There are some Kubernetes distribution that automatically create a RoleBinding for the namespace initiator, otherwise you will be left if the new resource, but without access in that particular namespace.

That's all fine, I just described what happenes if I don't apply a PolicyController/Admission Webhook to it.

[absoludity]

@absoludity I won't say that it is a bug, if you create a namespace in kubernetes using "kubectl create namespace XYZ", you will create that resource. Something must create the RoleBinding for that new namespace for you. There are some Kubernetes distribution that automatically create a RoleBinding for the namespace initiator, otherwise you will be left if the new resource, but without access in that particular namespace.

Riiight, ok, now I understand. Yes, it'd be unexpected for me, as a user, to have the ability to create a new namespace without being able to access it - I think we've always worked with the assumption that a non-privileged user won't be able to create new namespaces, and an admin user who can create namespaces can also view them.

That's all fine, I just described what happenes if I don't apply a PolicyController/Admission Webhook to it.

Great, this might be worth documenting for others?

[smerschjohann]

I would like to proceed on this one in the next days. What would be your approach here? My approach would be to add metadata information to the GRPC-Interfaces, in that way the corresponding package API (helm, ....) can filter on these information. The other approach would be to filter it on the final list and only show the packages/namespaces matching that criteria.

We could also do both to support package plugins, that do not support that kind of filter. Of course this filter is only needed for the "get me all packages in all namespace" feature otherwise we wouldn't request information to that namespace.

[absoludity]

Let's see what the others think, but I'd personally approach this using labels on namespaces, rather than using a block/safe list (as the latter needs some type of storage).

I would like to proceed on this one in the next days. What would be your approach here? My approach would be to add metadata information to the GRPC-Interfaces,

Right - so perhaps a namespacesFilterLabel configuration option to the kubeapps-apis service, which defaults to "" with no change in behaviour, but if set, only namespaces with that label will be returned or used in operations?

in that way the corresponding package API (helm, ....) can filter on these information.

+1

The other approach would be to filter it on the final list and only show the packages/namespaces matching that criteria.

-1 (I don't see any reason that the UI should know or care about this setting, it should just be controlled by the backend, IMO - but let's see what others say).

We could also do both to support package plugins, that do not support that kind of filter. Of course this filter is only needed for the "get me all packages in all namespace" feature otherwise we wouldn't request information to that namespace.

I don't think this last statement is true? In that, the UX also requests a list of namespaces to which the user has access (for the namespac switcher) and if not applied there, people can also switch to that namespace and request packages etc.