Description
Taking inspiration from a very similar operator: https://github.com/mittwald/kubernetes-replicator
In that operator, they allow you to pull secrets from one namespace into another. But only if you mark the source secret with a special annotation. This is to prevent someone who has access to create Secret resources in any namespace to just pull any secrets data from any other namespace.
Applying this to ClusterSecret would be quite straight forward.
Borrowing their example from the kubernetes-replicator's README, it could look like this:
apiVersion: v1
kind: Secret
metadata:
annotations:
clustersecret.io/replication-allowed: "true"
# Optional annotation to only allow its data to be synced into certain namespaces
clustersecret.io/replication-allowed-namespaces: "my-ns-1,namespace-[0-9]*"
data:
key1: <value>As this would be a breaking change, this would need an opt-in. Such as via environment variable or via command-line flag.
Edge case: bypassing via multiple ClusterSecrets
One way to bypass the clustersecret.io/replication-allowed-namespaces annotation would be to use ClusterSecret to load data of the secret, create a new secret into a namespace that is allowed, and then use a second ClusterSecret to load the new secret but with the namespaces annotation removed.
To counter this, any secrets created by ClusterSecret would forcefully have the clustersecret.io/replication-allowed: "false" annotation set. No matter what annotations the ClusterSecret resource says the secret should have.