Open Cajga opened 1 year ago
For tangerine to spike this work
@yiannistri please share the notes you mentioned earlier.
@enekofb I have attempted to install Weave GitOps in its own namespace with its own service account. We can use this as a starting point to determine what RBAC permissions we could drop (if any) in order to better support the use case mentioned above. If it helps, see my comment here.
@yiannistri, maybe I am missing the connection but our concern is about the permissions that are required for the impersonated user and not for the SA of weave-gitops.
Our users (and possibly users of many clusters where flux multitenancy is in use) have only access to their own namespaces (plus they are able to list namespaces) and that is it. With this, they can work with flux cli
(or kubectl
) to verify their HelmReleases
or Kustomizations
. But with weave-gitops, nothing shows up on the dashboard at the moment.
@Cajga the use case you describe makes sense. My suggestion was about the first step towards a solution, which would allow users to run Weave GitOps in its own namespace, instead of flux-system
. Then we should evaluate what changes are needed (in RBAC and Go code) to support what you describe.
@yiannistri thanks for the confirmation.
When I am dealing with RBAC, I use this tool heavily: https://github.com/liggitt/audit2rbac
I thought to mention it in case you do not know it. If it helps then I can make some tests and list here the RBAC that is needed for waeve-gitops installation in it's own namespace.
Checking on this as this still makes weave-gitops
unusable when flux multi-tenancy and OIDC is enabled for the cluster and for weave-gitops
.
Problem
We use flux multi-tenancy for our clusters. Kubernetes roles are bind to groups coming from OIDC provider (AzureAD). Tenants only receive access to their own namespaces and on top of this, they have rights to list all namespaces. They do not have any access to anything else (no access to flux-system namespace). Weave-gitops is configured with OIDC auth using the same parameters than the kube-apiserver. Auth works well.
With this config, we expected that users will only see resources on the dashboard that are inside the namespaces that they have access to. But is seems, they do not see any data. If I assign the cluster-admin role to one of these users, this users starts to see every resource on the dashboard (so seems the problem relies in kubernetes RBAC permissions).
Based on the documentation, it seems, users have to have access to the flux-system namespace. Actually, our tenants has nothing to do with that namespace as they only deal with resources (also flux CRs) in their own namespaces.
Solution
We would like that users who have only access to specific namespaces can see their resources in weave-gitops dashboard without the need to give them extra, unnecessary permissions.