You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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: v1kind: Secretmetadata:
annotations:
clustersecret.io/replication-allowed: "true"# Optional annotation to only allow its data to be synced into certain namespacesclustersecret.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.
The text was updated successfully, but these errors were encountered:
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:
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.The text was updated successfully, but these errors were encountered: