Support for blueprint on different namespace of kanister operator

[khahv]

Is your feature request related to a problem? Please describe.
It's not actually a problem, I just want to create a blueprint on a different namespace with kanister operator

Describe the solution you'd like
By default as I tested the examples, if the kanister-operator was installed in kanister namespace, then the blueprint must also be installed in the kanister namespace. Otherwise, the event of profile will show "none" after created.

Describe alternatives you've considered
Now I want kanister to support for creating the blueprint in another namespace, like I want to create mysql-blueprint in mysql-test namespace, or postgresql-blueprint in postgres-test namespace.

Environment
Kubernetes Version/Provider: All
Storage Provider: .All
Cluster Size (#nodes): Any
Data Size: Any

Additional context
No

[github-actions[bot]]

Thanks for opening this issue 👍. The team will review it shortly.

If this is a bug report, make sure to include clear instructions how on to reproduce the problem with minimal reproducible examples, where possible. If this is a security report, please review our security policy as outlined in SECURITY.md.

If you haven't already, please take a moment to review our project's Code of Conduct document.

[ihcsim]

This will require granting the Kanister controller RBAC permissions to retrieve blueprints, actionsets, profiles etc. from other namespaces, which may not work for some users. Can you share more information on your setup and use cases as to why it's desirable to deploy blueprints to other namespaces?

[khahv]

Hi @ihcsim, it's simply the way I'm trying to manage the source code, I want mysql-blueprint to placed in same group of mysql application, same as mysql-profile. While profile of specific app can be placed in other namespaces but blueprint of the same app cannot? Hope that make sense. Thanks.

[dsu-igeek]

When we look into this, we need to be sure that this doesn't give a path for privilege escalation.

Also, we currently have the ability to run multiple Kanister installations in the same cluster, need to look at which Kanister install would be looking at namespaces, could be an option in the Kanister install for which namespaces it looks at. Default could continue to be the namespace it is installed in, "*" for all namespaces or a list.

[ihcsim]

We should re-evaluate the current pod service account model. See #1550.

I find supporting the upgrade path of a multi-installation model hard to reason about, especially, for cluster-scoped resources. Feels like we should re-visit our multi-tenancy story.

[github-actions[bot]]

This issue is marked as stale due to inactivity. Add a new comment to reactivate it.

[github-actions[bot]]

This issue is closed due to inactivity. Feel free to reopen it, if it's still relevant.

[exciler]

After a short discussion on slack, I would like to reopen this issue.

I would like to use Kanister in the following setting/environment:

• multiple teams develop apps together with corresponding manifests in separate git repositories
• manifests in those repos are deployed to the k8s cluster via gitops into separate namespaces (at least every team has a separate namespace but some large apps also have a dedicated namespace)
• teams should be able to deploy blueprints and actionsets together with the app manifests through those git repos via GitOps
• blueprints of Team A should not be able to modify blueprints of Team B

Currently this would only be possible by deploying a kanister-operator in every namespace which would not be a good solution. Problem would be solved if Kanister would scan for Blueprint/ActionSet-Resources in selectable/all namespaces.

[alexander-bauer]

Migrating my question from Slack to here: I'm trying to apply Kanister for my home cluster backups, and the model makes sense to me with one big exception: it seems to me that Blueprints and ActionSets related to specific applications have every reason to live in the same namespace with that application, but it doesn't seem like Kanister supports that, nor has a clear "happy-path" for me.

In my case, applications are deployed by Terraform modules into dedicated namespaces, and all domain-specific knowledge about each application is captured in its module. Having to put Kanister resources in a different namespace will require each module to encode knowledge about how I have Kanister deployed (that is, which namespace), rather than simply using its CRDs. (Actually, that's assuming that I can have ActionSets in the kanister namespace operate on resources in other namespaces, which I'm not sure is the case.)

Other operators (such as cert-manager) operate by default in all namespaces, and so feel somewhat like native extensions to Kubernetes -- as an application owner, I don't need any particular knowledge about the cert-manager operator's deployment, or even much about the PKI structure: I just describe Certificate objects in the same namespace as my application, and cert-manager fulfills the request.

With Kanister, I'm not quite sure what the Right Way™ looks like for me. With no knowledge of the code base, if I could snap my fingers and adjust the architecture, I would take inspiration from the Gateway API's multiple-personas model. That is, there are:

• Profiles (and perhaps other cluster-scoped or kanister-namespace resources) owned by an infrastructure provider persona, which can be used to inject credentials and backup destination configuration;
• Blueprints developed by application owners, requiring domain-specific knowledge such as how it should be quiesced;
• and ActionSets supplied by cluster operators, requiring knowledge of things like maintenance windows.

This earlier comment brings up RBAC concerns. I can certainly imagine organizations where Kanister's current model makes more sense, but if I were in an organization with such controls, I'd be leery of relying on the Helm chart's bundled RBAC in any case. I'd probably supply my own RBAC limited to the one or more namespaces I expected Kanister to operate in, rather than deploy Kanister once for each namespace.

Anyhow, I'd really appreciate some insight from others on how Kanister might apply to a situation like mine, and whether there's already a "happy path."

[viveksinghggits]

Hi @alexander-bauer,
Those are some really great points and like you noticed we have had discussions about supporting actionset creation in the application namespace so that all the kanister resources can be created in the application namespace and whoever is managing that namespace wouldn't need permissions to create resources in another namespace.
We discussed this yesterday in the community call and we think that it's a good idea to pursue this. We will discuss this more to make sure that this doesn't conflict with the fundamental design of Kanister and will keep you updated.