-
Notifications
You must be signed in to change notification settings - Fork 20
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
feat(api): add multi-namespace ClusterCryostat API #520
feat(api): add multi-namespace ClusterCryostat API #520
Conversation
Thanks for the explanation writeup, it sounds like it makes a lot of sense to me. Building and manual testing everything looks great too. It'll take some time to work through the patch review but I'll be looking at it this week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. I'm sure we'll find things that need adjusting between this and the various Cryostat changes that are also in the pipeline around this story, but we'll see what happens when everything gets done and tested together.
I've seen this error come up a couple times, but I'm not sure what causes it.
|
In the most recent occurrence, I noticed that I deployed the operator using the From https://sdk.operatorframework.io/docs/building-operators/golang/operator-scope/#overview:
If this is the cause of the error, perhaps we want to disable the ClusterCryostat controller for |
This last sentence doesn't seem to match up with what I'm seeing. The underlying Informer will restrict list/watches to a set of namespaces, if provided. This doesn't happen for cluster-scoped resources though:
I've tried this and still encounter the error. I'm now able to reliably reproduce it:
Still no idea why this is happening, but it's pretty bad. So I'm going to hold off on merging until we can figure this out. At least now we have a reproducer. |
Fixed now, it was just a typo in the |
* Add ClusterCryostat type and controller * Use abstraction for tests * Make CR name in tests configurable * Refactor tests to share between APIs * Run tests for ClusterCryostat controller * Implement RBAC per target namespace * Pass CRYOSTAT_K8S_NAMESPACES to deployment * Fix generated files with operator-sdk * Use ClusterCryostat as initialization-resource * Use Kustomize patch to adjust x-descriptors * Use Kustomize patch to add x-descriptors to targetNamespace elements * Regenerate bundle * Add note on multi-tenancy * Use common SetupWithManager * Rename reconciler interface * Use cluster role instead of role * Restore role permission * Add new cluster role to bundle, fix logging * Rename Instance to Object * Don't default to installNamespace * Fix list item typo
* Add ClusterCryostat type and controller * Use abstraction for tests * Make CR name in tests configurable * Refactor tests to share between APIs * Run tests for ClusterCryostat controller * Implement RBAC per target namespace * Pass CRYOSTAT_K8S_NAMESPACES to deployment * Fix generated files with operator-sdk * Use ClusterCryostat as initialization-resource * Use Kustomize patch to adjust x-descriptors * Use Kustomize patch to add x-descriptors to targetNamespace elements * Regenerate bundle * Add note on multi-tenancy * Use common SetupWithManager * Rename reconciler interface * Use cluster role instead of role * Restore role permission * Add new cluster role to bundle, fix logging * Rename Instance to Object * Don't default to installNamespace * Fix list item typo
This PR adds a new ClusterCryostat CRD. This is essentially a cluster-scoped version of the Cryostat CRD with a couple of additions. Instead of installing Cryostat into the same namespace of the CR, the ClusterCryostat CRD has an
Spec.InstallNamespace
property. Then there is theSpec.TargetNamespaces
property where the user can specify which namespaces they want this Cryostat instance to work with. The operator accomplishes this by creating a RoleBinding in each of these namespaces, binding the CR's service account to the Cryostat Role (now a Cluster Role to save resources).The reasoning for making a new CRD instead of using the existing Cryostat is to guard against unexpected privilege escalation. OLM-installed operators automatically aggregate view, edit, and admin permissions for each CRD to the corresponding Cluster Roles using role aggregation. A cluster-admin might give an unprivileged user admin or edit permissions for a particular namespace by binding the admin or edit cluster role to that user. This cluster-admin may not expect that giving such permissions to a user would allow them to create a Cryostat CR that in turn creates a multi-namespace Cryostat installation through the
Spec.TargetNamespaces
field. By making ClusterCryostat cluster-scoped, the only way to allow unprivileged users to create one is by a cluster-admin explicitly creating a Cluster Role Binding for a user. This action makes it explicit that the user will be authorized to monitor as much of the cluster as they wish with Cryostat.Here is an example for a user "developer" that has the "admin" role bound to it in the current namespace:
In order to not break API between minor releases and to allow unprivileged users to still create single-namespace Cryostat installations as before, the existing Cryostat CRD remains. Much of the code changes of this PR are to make the controller and test code able to handle an abstraction of the two CRDs, called
CryostatInstance
in the new model package.I had to make test changes in quite a few places to avoid hardcoding the "cryostat" CR name for all created resources. This is necessary because for cluster-wide CRs we want to be able to test with two (differently named) CRs at once to ensure they don't conflict with each other.
To test in OpenShift:
Fixes: #513