Bind installations to clusters instead of users

[ncbkr]

Use Case

It would be great if installations could be bound to a cluster. We have many different cluster set up. we observe that switching between service accounts and managing user to service account mappings is becoming error prone and difficult to maintain.

If installations were bound to clusters, the service accounts would be a lot easier to maintain. As this way, service accounts can have multiple clusters in multiple cloud platforms.

Ideas of Implementation

Additional Info

---

Message from the maintainers:

Excited about this feature? Give it a 👍. We factor engagement into prioritization.

[davidspek]

Another reason to bind installations to clusters, is that this opens up the possibility to “share” clusters between users in an account. This can be particularly useful, for example, if another user needs to be able to change the OIDC configuration of an application or uninstall an application or package in our API.

While a service account somewhat solves for this problem, the fact is that people will create an account in Plural and a user will deploy a cluster without thinking of these limitations. After which all the apps deployed on that cluster can only be managed by that single user.
A perfect example of this is our own production cluster that runs Plural.

I think traditionally a service account is more like a way for another service or workload to access something (an account for a service with certain bound permissions), and not really an analogue for standard users.

[davidspek]

Another reason, as @ncbkr already mentioned, is that currently users are pinned to a specific cloud provider as otherwise the app upgrade streams will collide. For example, the GCP specific packages would get deployed in an AWS cluster/repository.

Pinning the cloud provider to users has already caused issues when people try and switch between providers in their account. A common example for this happening is a user first deploying a local KinD cluster to test Plural, and afterwards trying to deploy a production cluster on one of the cloud providers. It causes a lot of user friction to need to explain to them how to unpin their user from one cloud provider before using another.

[davidspek]

Another issue related to this is that trying to run Plural in CI to test an application would mean a new Plural service account will need to be made in each CI run since installations are user bound and not cluster bound.