Minimal rbac to view and reconcile resources in UI

[adberger]

trafficstars

Hi there

We are currently trying to limit the flux resources which a specific user/group can see & use (e.g. sync). We tried to apply the following role, but the user doesn't see any resources matching the names specified.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: example
  namespace: tenant-1
- apiGroups:
  - kustomize.toolkit.fluxcd.io
  resourceNames:
  - example-kustomization
  resources:
  - kustomizations
  verbs:
  - get
  - list
  - watch
  - patch
- apiGroups:
  - source.toolkit.fluxcd.io
  resourceNames:
  - example-gitrepository
  resources:
  - gitrepositories
  verbs:
  - get
  - list
  - watch
  - patch

The following requests over kubectl work:

kubectl get kustomizations.kustomize.toolkit.fluxcd.io -n tenant-1 example-kustomization
kubectl get gitrepositories.source.toolkit.fluxcd.io -n tenant-1 example-gitrepository

Additionally setting

  # Read access for all other Kubernetes objects
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: [ "get", "list", "watch" ]

according to the docs, the user can see "too much".

[jpellizzari]

@adberger Thanks for the report. This is a known issue, and one that cropped up for me again in a different form this week.

The root cause of this is how we determine whether a user can "see" a namespace:

https://github.com/weaveworks/weave-gitops/blob/f69ed59f72e682330022dd7ce8217341944e0e8a/core/nsaccess/nsaccess.go#L67

Kubernetes doesn't have a concept of "yes you can see this namespace", because it only knows about verbs against kinds in a namespace, so we layered on the access logic to convert it to a bool.

We aren't handling the resourceName case at the moment.

[adberger]

@jpellizzari I see, that's unfortunate.

We now do it like this for the moment:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: example
  namespace: flux-system
rules:
- apiGroups: [""]
  resources: ["pods", "secrets", "events"]
  verbs: ["get", "list"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list"]
- apiGroups: ["kustomize.toolkit.fluxcd.io"]
  resources: ["kustomizations"]
  verbs: ["get", "list"]
- apiGroups: ["kustomize.toolkit.fluxcd.io"]
  resources: ["kustomizations"]
  resourceNames:
    - exampleResource
  verbs: ["patch"]
- apiGroups: ["helm.toolkit.fluxcd.io"]
  resources: ["helmreleases"]
  verbs: ["get", "list"]
- apiGroups: ["source.toolkit.fluxcd.io"]
  resources: ["buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories"]
  verbs: ["get", "list"]
- apiGroups: ["source.toolkit.fluxcd.io"]
  resources: ["gitrepositories"]
  resourceNames:
    - exampleResource
  verbs: ["patch"]
- apiGroups: [""]
  resources: ["events"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: example
  namespace: flux-system
subjects:
- kind: Group
  name: groupXY
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: example
  apiGroup: rbac.authorization.k8s.io

The users can see everything, but only sync their resources.

[yiannistri]

I'm afraid we need more time to test this change.

[squaremo]

I think the problem in the original report is that Weave GitOps wants to be able to see groups and resources in addition to "sources.toolkit.fluxcd.io" and "kustomization.toolkit.fluxcd.io" (the requirements are expressed as rules in https://github.com/weaveworks/weave-gitops/blob/main/core/nsaccess/nsaccess.go). Having resourceNames in a rule doesn't cause problems -- it's present in the example of RBAC that does work.

[adberger]

I think the problem in the original report is that Weave GitOps wants to be able to see groups and resources in addition to "sources.toolkit.fluxcd.io" and "kustomization.toolkit.fluxcd.io" (the requirements are expressed as rules in https://github.com/weaveworks/weave-gitops/blob/main/core/nsaccess/nsaccess.go). Having resourceNames in a rule doesn't cause problems -- it's present in the example of RBAC that does work.

Sure, my provided example works, but with this configured, every user see every flux resource of a namespace in the UI (which is not intended) but can only sync their resources (which is intended).

I would like to specify an rbac like this:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: example
  namespace: flux-system
rules:
- apiGroups: [""]
  resources: ["pods", "secrets", "events"]
  verbs: ["get", "list"]
- apiGroups: ["apps"]
  resources: ["deployments", "replicasets"]
  verbs: ["get", "list"]
- apiGroups: ["kustomize.toolkit.fluxcd.io"]
  resources: ["kustomizations"]
  resourceNames:
    - exampleResource
  verbs: ["get", "list", "patch]
- apiGroups: ["helm.toolkit.fluxcd.io"]
  resources: ["helmreleases"]
  verbs: ["get", "list"]
- apiGroups: ["source.toolkit.fluxcd.io"]
  resources: ["buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories"]
  resourceNames:
    - exampleResource
  verbs: ["get", "list", "patch"]
- apiGroups: [""]
  resources: ["events"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: example
  namespace: flux-system
subjects:
- kind: Group
  name: groupXY
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: example
  apiGroup: rbac.authorization.k8s.io

[squaremo]

every user see every flux resource of a namespace in the UI (which is not intended) but can only sync their resources (which is intended)

Right, the access you need to give people so they can see namespaces in the UI, is (much) more than just ["list", "get"] on some subset of Flux resources in those namespaces.

I can see why having more access makes the display richer (you can display the status of workloads, say), but you ought to be able to see your stuff in the UI if you can access it via RBAC. "Ought" as in: Weave GitOps does not do this, and it would be better if it did.

[adberger]

Any progress on this concern?

[lasomethingsomething]

@bigkevmcd and @foot Can you please take a look at this?

[bigkevmcd]

@LappleApple I guess we could take the original attempt, and improve it by looking for the presence of the named resources (resourceNames) in the checked ns, this would restrict to only namespaces where the named resources are present.

Not sure when we would get a chance to do this tho'