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; NoClusterRoleBinding
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 .
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 4
- Comments: 18 (8 by maintainers)
@josvazg Thank you so much for working on that!