kubeapps
kubeapps copied to clipboard
vmware-tanzu
Devault View user cannot view applications
Description:
A user created with the kubernetes user-facing role "view" cannot see applications when using Kubeapps.
When logging into Kubeapps, the following error is displayed instead: "Unable to list apps: Forbidden error, missing permissions: apiGroup: "", resource: "secrets", action: "list", namespace: system-kubeapps".
Steps to reproduce the issue:
Either use a user (if using SSO) or a service account, and create a cluster role binding to the "view" cluster role. This kubernetes user-facing role is a default way to support the customary "viewer" roles in many software.
Also create a cluster role binding to the cluster role "kubeapps:system-kubeapps:apprepositories-read", otherwise the user will not be able to view repositories.
Deploy an application using helm (e.g. nginx from the bitnami repository)
Login to Kubeapps as the "viewer" user created above. The user will be able to view repositories and charts in the catalog, but it will not be able to view applications.
Describe the results you received:
received the following error message displayed in the UI: "Unable to list apps: Forbidden error, missing permissions: apiGroup: "", resource: "secrets", action: "list", namespace: system-kubeapps".
Describe the results you expected:
As the user has full "view" on the cluster, the user is capable of viewing deployments, pods etc... and I expected the user to be able to view applications in the UI.
Additional information you deem important (e.g. issue happens only occasionally):
The message clearly indicates that the issue is with not having the "list" permissions for secrets. The kubernetes "view" role does not allow data sensitive / security permissions, and more explicitely does not grant "list secret". Helm is using "secrets" to encode its deployment history and state.
This gives a situation where by default, helm is not really compatible with standard security practices from kubernetes as it relies on secrets as markers for applications, preventing "viewer" roles (giving "list secret" permissions to viewer roles would go against kubernetes security practices).
I would expect Kubeapps to provide a way to be able to identify applications without relying on secrets in order to support all standard roles. (one common way is to generate an associated ConfigMap resource)
The message clearly indicates that the issue is with not having the "list" permissions for secrets. The kubernetes "view" role does not allow data sensitive / security permissions, and more explicitely does not grant "list secret". Helm is using "secrets" to encode its deployment history and state.
Right, this is the key, imo. Up until this point, Kubeapps has been a UI on top of Helm only. Given that Helm uses secrets to store the release information, you similarly cannot helm ls to see your installed charts with the view (I assume), when using the default Helm secrets storage. Given that you can't do this in Helm, you can't do it in Kubeapps (currently).
This gives a situation where by default, helm is not really compatible with standard security practices from kubernetes as it relies on secrets as markers for applications, preventing "viewer" roles (giving "list secret" permissions to viewer roles would go against kubernetes security practices).
I assume Helm does this because the values.yaml (which is stored with the release info) may contain secret data. Whether that's bad practise or not is not so relevant as it being possible for chart authors to do so, so secrets are used by default (just my hypothesis), while allowing people to intentionally specify configmaps as the storage backend.
I would expect Kubeapps to provide a way to be able to identify applications without relying on secrets in order to support all standard roles. (one common way is to generate an associated ConfigMap resource)
If we were doing that, why not just support the ConfigMap backend storage for Helm (which we don't currently), and document that people need to use that if they want to enable view access.
There would be other things requiring fixing too (such as ensuring that when viewing an app, we don't log the user out when the app tries to fetch a secret, but we've wanted to stop Kubeapps from fetching secrets unless requested anyway, so that would be a great opportunity to do so).
the issue with using ConfigMap is that this is not secure (or difficult to secure). See the helm doc: https://helm.sh/docs/topics/advanced/#storage-backends
the issue with using ConfigMap is that this is not secure (or difficult to secure). See the helm doc: https://helm.sh/docs/topics/advanced/#storage-backends
Yes, that's what I meant above by "I assume Helm does this because the values.yaml (which is stored with the release info) may contain secret data.". It could only be used if people explicitly turned it on.
But if that's not what you meant, the only other option (which I assume you meant, re-reading) would be for Kubeapps to add its own Config map to record each release? This would mean Kubeapps diverges from helm in a way we've tried to avoid. Charts deployed via the Helm CLI wouldn't be visible to the viewer, while those deployed via Kubeapps would. I'm not sure that's going to be helpful. Or did you mean something else?
I did indeed mean that Kubeapps should inject its own ConfigMap. But you are bringing some good points: how many ConfigMap resources would we need (is one enough or do we need one per version), and apps installed via helm CLI would not be visible (they are not visible today anyway).
and apps installed via helm CLI would not be visible (they are not visible today anyway).
They should be visible today? Kubeapps just requests the helm releases in the namespace. If you install Kubeapps via the helm CLI, then login, browse the installed apps in the kubeapps namespace, you should see Kubeapps (same goes for any other CLI-installed app). Let me know if I'm missing something.
What i meant is that today, with a view only role, helm installed apps (either kubeapps or CLI) are not visible in Kubeapps UI. Even if we were able to inject an extra ConfigMap when installing via Kubeapps, helm CLI would not be injecting that ConfigMap, so we would be able to view apps deployed by Kubeapps, but not the one deployed by helm CLI. This would not be a complete solution.
I found that this use-case is described in the following documentation: https://github.com/kubeapps/kubeapps/blob/master/docs/user/access-control.md#read-access-to-applications-within-a-namespace
the documentation should probably be updated to reflect that a "view" role is not enough to view applications as there is no access to secrets.
I found that this use-case is described in the following documentation: https://github.com/kubeapps/kubeapps/blob/master/docs/user/access-control.md#read-access-to-applications-within-a-namespace
Yep, could be that it was originally written when Kubeapps used helm 2 which had tiller, a component that ran in the cluster with its own service account. It's been edited since then, so not 100%.
the documentation should probably be updated to reflect that a "view" role is not enough to view applications as there is no access to secrets.
+1, if you have time and are in the head-space, please send a PR - it would be really helpful to incrementally fix things like this.