search

operator-framework / operator-controller

A new and improved management framework for extending Kubernetes with Operators
https://operator-framework.github.io/operator-controller/
Apache License 2.0
50 stars 53 forks source link

Sample ArgoCD: List requests fail due resourceName in the RBAC rule #1195

Closed m1kola closed 2 weeks ago

m1kola commented 2 weeks ago

I'm seeing the following logs from operator-controller-controller-manager after applying config/samples/olm_v1alpha1_clusterextension.yaml.

W0830 08:35:24.701403       1 reflector.go:561] pkg/mod/k8s.io/client-go@v0.31.0/tools/cache/reflector.go:243: failed to list apiextensions.k8s.io/v1, Kind=CustomResourceDefinition: customresourcedefinitions.apiextensions.k8s.io is forbidden: User "system:serviceaccount:argocd:argocd-installer" cannot list resource "customresourcedefinitions" in API group "apiextensions.k8s.io" at the cluster scope
E0830 08:35:24.702206       1 reflector.go:158] "Unhandled Error" err="pkg/mod/k8s.io/client-go@v0.31.0/tools/cache/reflector.go:243: Failed to watch apiextensions.k8s.io/v1, Kind=CustomResourceDefinition: failed to list apiextensions.k8s.io/v1, Kind=CustomResourceDefinition: customresourcedefinitions.apiextensions.k8s.io is forbidden: User \"system:serviceaccount:argocd:argocd-installer\" cannot list resource \"customresourcedefinitions\" in API group \"apiextensions.k8s.io\" at the cluster scope" logger="UnhandledError"

Looking at the manifest I see the following:

https://github.com/operator-framework/operator-controller/blob/04ee036ace55df04451375e4a8d8ab283c8e1c43/config/samples/olm_v1alpha1_clusterextension.yaml#L37-L48

Note that we allow list here, but we also restrict by resourceNames.

Here is what the documentation says:

You cannot restrict create or deletecollection requests by their resource name. For create, this limitation is because the name of the new object may not be known at authorization time. If you restrict list or watch by resourceName, clients must include a metadata.name field selector in their list or watch request that matches the specified resourceName in order to be authorized. For example, kubectl get configmaps --field-selector=metadata.name=my-configmap

m1kola commented 2 weeks ago

Easy fix is to get rid of resourceNames, but then we allow access to all CRDs. If we want to maintain resourceNames then the client (helm?) needs to be aware of the resource names somehow.

joelanford commented 2 weeks ago

I believe this will be fixed by #1119

joelanford commented 2 weeks ago

If we want to maintain resourceNames then the client (helm?) needs to be aware of the resource names somehow.

In order for creates to work with a resourceName, we need helm to use an apply patch rather than a create call. I don't think there is a way to get around the global list and watch permissions though. The boundaries for list and watch permissions are either:

m1kola commented 2 weeks ago

Closing as a duplicate of #1195