-
Notifications
You must be signed in to change notification settings - Fork 29
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
Ability to limit the operator's scope to specific Kubernetes namespaces #291
Comments
I'm very interested in this capability, I'm also at a place where providing I'd be interested in doing the work, if the following proposal made sense: ProposalIntroduce When present, the operator will only look for relevant CRDs in those namespaces. The SpiceDB cluster itself will be created in the same namespace as the CRD. Rolebindings (namespace scoped) will need to be setup by the human(s) accordingly. To ensure backwards compatibility, the absence of |
Hi @joshrosso, thanks for the interest! I think your proposal will work fine (it's how most operators do it), and I'm okay with doing that for now if we need to. But I've always thought the UX would be much better if we did something like this:
In the default (all namespace) installation, we'll create a If you want to let the operator work in just one namespace, i.e. Similarly, if you have The nice thing about this model is that, because the operator retains R/W control on the There's two main issues with this:
We could also think about doing this type of thing for some api calls; i.e. maybe you create an operator that can't create With respect to your proposal, this could be a "phase2" and part of the default behavior if the namespace list is omitted? |
@ecordell All the above makes sense to me and I like the UX you proposed. If you're cool with the 2 phase approach, as you mentioned:
I'm on board. I'll try to work through an implementation and PR this week for phase 1. |
The base support is available in 1.17.0, and i've filed the other idea as a separate issue #341 |
I'm currently trying to set up the spicedb-operator in our Kubernetes cluster but I'm running into an issue around permissions. Currently the operator is failing to start in our cluster because it seemingly doesn't have cluster-scoped permissions it expects.
For security reasons, most permissions required by the operator have to be namespace-scoped in our clusters.
Can functionality be added to support scoping the operator's actions to specific Kubernetes namespaces?
This is the current RBAC configuration given to our
spicedb-operator
service account.ClusterRole
Role (limited to
spicedb-auth
namespace)Error logs from the
spicedb-operator
containerThe text was updated successfully, but these errors were encountered: