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

Allow users without access to flux-system to use the dashboard #4036

Open
Cajga opened this issue Sep 20, 2023 · 7 comments
Open

Allow users without access to flux-system to use the dashboard #4036

Cajga opened this issue Sep 20, 2023 · 7 comments
Labels

Comments

@Cajga
Copy link

Cajga commented Sep 20, 2023

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.

@enekofb
Copy link
Contributor

enekofb commented Sep 20, 2023

For tangerine to spike this work

@enekofb enekofb added severity/high low < medium < high < critical area/security labels Sep 20, 2023
@enekofb
Copy link
Contributor

enekofb commented Sep 20, 2023

@yiannistri please share the notes you mentioned earlier.

@yiannistri
Copy link
Contributor

@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.

@Cajga
Copy link
Author

Cajga commented Sep 22, 2023

@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.

@yiannistri
Copy link
Contributor

@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.

@Cajga
Copy link
Author

Cajga commented Oct 2, 2023

@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.

@Cajga
Copy link
Author

Cajga commented Feb 19, 2024

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.

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

No branches or pull requests

3 participants