sealed-secrets: Watch `Secret` permission introduced by PR #963 breaks dynamic low-privilege multi-tenant set-ups

Which component

controller

Describe the bug

Due to the implementation of #963 , versions of the sealed secrets controller >= v0.19.0 are no longer installable in dynamic low-privilege multi-tenant environments. The properties of the environment are:

• multi-tenant: Namespaces are isolated “per tenant”
• low-privilege: The sealed secret controller must only access resources of kind Secret in specific namespaces; No ClusterRoleBinding can be used.
• dynamic: Namespaces are added/removed in a high frequency.

The implementation of #568 already allows watching only specific namespaces. However, this static list must be adapted whenever a namespace is added / removed.

Possible solutions

Dynamically create Secret for namespaces that contain SealedSecret resources

Whenever the sealed secret controller picks up a new SealedSecret resource, it creates a watch for Secret resources within the same namespace, unless a watch already exists. Whenever a SealedSecret resource is deleted, the watch for Secret resources within the same namespace is removed, if it was the last SealedSecret in the same namespace.

Watch Namespaces for specific labels to include

Instead of maintaining a static list of namespaces when deploying the controller, the controller could watch namespace resources for a specific label (e.g. sealed-secrets: enabled). If the label is present, the controller creates watches for Secret (and SealedSecret?) resources.

Feature flag for #963

Another option could be a feature flag to disable the behavior introduced by #963 .