Open jgarcia-sqsp opened 7 months ago
I'm very interested in this capability, I'm also at a place where providing spicedb-operator
cluster-wide access is problematic. In my case, I really only need it tied to a single namespace.
I'd be interested in doing the work, if the following proposal made sense:
Introduce --watch-namespaces
argument to the spicedb-operator
cmd. It can support a list of namespaces, separated by commas.
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 --watch-namespace
(default) will mean the operator continues to work at a cluster-wide level.
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:
ClusterRole
/ClusterRoleBinding
), we'll call it spicedbcluster-rw
. ClusterRole
for managing SpiceDB-related resources in a namespace; i.e. deployment create
, service create
. Let's call this manage-spicedb
In the default (all namespace) installation, we'll create a ClusterRoleBinding
to manage-spicedb
. Then the operator can do its work in any namespace.
If you want to let the operator work in just one namespace, i.e. my-spicedbs
, then you could instead create a RoleBinding
to manage-spicedb
in my-spicedbs
for the operator's service account. Now the operator has permission to create deployments
only in my-spicedbs
.
Similarly, if you have dev-spicedbs
, staging-spicedbs
, and prod-spicedbs
namespaces, you can create one RoleBinding
per namespace to grant the operator permission to work.
The nice thing about this model is that, because the operator retains R/W control on the SpiceDBCluster
object in the entire cluster, it will be able to do things like write a status message in the object when permission is insufficient: Error: Operator does not have permission to list Deployments in namespace foo, please grant etc etc...
, with explicit instructions for users to follow (if they have sufficient permission to perform them).
There's two main issues with this:
SpiceDBCluster
objects as they are created, and either report an error on the object or start reconciling. We don't start and stop watches dynamically like this in the spicedb-operator
right now, though https://github.com/authzed/controller-idioms supports it (and we use it in some internal controllers at authzed). 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 Jobs
- so it can run spicedb but will error if it tries to run a migration. There might be some cases where this is useful; if you need to pre-provision serviceaccounts or something and don't want the operator to have permission to create them at all.
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:
With respect to your proposal, this could be a "phase2" and part of the default behavior if the namespace list is omitted?
I'm on board. I'll try to work through an implementation and PR this week for phase 1.
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
container