Example errors logged by the operator container: "E0216 15:58:45.546614 1 reflector.go:147] pkg/mod/github.com/ecordell/client-go@v1.28.0-patchmeta/tools/cache/reflector.go:229: Failed to watch batch/v1, Resource=jobs: failed to list batch/v1, Resource=jobs: jobs.batch is forbidden: User "system:serviceaccount:spicedb-operator:spicedb-operator" cannot list resource "jobs" in API group "batch" at the cluster scope"

Feel free to open an issue on the GH repo though

the UX of namespace-restricted controllers can be frustrating

becuase the type is always available globally in the cluster

Hi, until this issue is hopefully addressed we're thinking of granting the operator a subset (list and watch verbs) of Cluster-scoped permissions to get it up and running, we'd then give it the other permissions it requires at the Namespace level. The only caveat here is that we wouldn't grant it the Cluster-scoped watch verb on "secrets" since that would give it access to sensitive information. However this means the operator is constantly logging errors becuase it can't watch this resource - Is this fine? Would this is any way negatively affect the operator? From testing this so far everything seems to work fine and we're able to create and upgrade clusters, it's just that the operator constantly logs these errors.

E.g I0223 14:10:41.658452 1 reflector.go:325] Listing and watching /v1, Resource=secrets from pkg/mod/github.com/ecordell/client-go@v1.28.0-patchmeta/tools/cache/reflector.go:229 E0223 14:10:41.662630 1 reflector.go:147] pkg/mod/github.com/ecordell/client-go@v1.28.0-patchmeta/tools/cache/reflector.go:229: Failed to watch /v1, Resource=secrets: unknown

@ecordell Was wondering if you would advice against this or not? It's not ideal but it'd get us around this issue and would allow us to set up our clusters through the operator. The alternative would be to manually deploy and manage our spicedb clusters in Kubernetes without the help of the operator, then we'd eventually (once the operator permissions can be more tightly scoped to specific namespaces) adopt the operator to take over management of our clusters.

so if you're missing the datastore_uri or use the wrong key or something, the operator won't be able to tell you about it

The operator actually opens a label-filtered watch against the kube api - it doesn't have access to all secrets, even though the RBAC is defined for that. There's no way to indicate a label filter on RBAC itself, unfortunately. Depending on what you're worried about, you could try giving the operator list/watch/get on secrets but not delete/update/create. Then when you make a secret for a SpiceDBCluster, add

authzed.com/managed-by: operator

as a label. That will make the secret visible to operator for validation, but you won't have to worry about the write permissions on secrets.