Low-privilege, self-service deployments in shared clusters

Currently we assume a cluster admin will be willing to install sealed secrets controller globally.
This assumption doesn't hold for all of our users.

Many people end up with a shared k8s cluster where they get access to one namespace (or a handful of)

We should allow such users to self-service and deploy their own instance of the sealed-secrets controller that will serve their own sealed secrets resources in their own namespace.

It's not yet clear if we should limit this to only one namespace or whether the controller should operate on all sealed secrets resources the RBAC rules allow such a service account to access.

In any case we need to devise a mechanism for multiple controllers to avoid stomping on each others. Since each controller will have a different set of private keys, the effects of stomping on each other will not primarily affect correctness as such, but pollute logs, create spurious k8s events and possibly have unwanted side effects on work queue retries etc.

Start by reviewing the sealed-secrets controller's deployment and RBAC behavior across namespaces; the issue does not name specific files or tests. Define the permitted namespace scope and a mechanism for multiple controllers to coexist without log, event, or work-queue interference, then validate self-service deployment for low-privilege users.

Written by the indexing model from the issue text.