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]

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]

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

[github-actions]

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.