This repository contains a custom Kubernetes controller that can be used to make secrets and config maps available in multiple namespaces.
-
$ helm repo add mittwald https://helm.mittwald.de "mittwald" has been added to your repositories $ helm repo update Hang tight while we grab the latest from your chart repositories... ...Successfully got an update from the "mittwald" chart repository Update Complete. ⎈ Happy Helming!⎈
-
Upgrade or install
kubernetes-replicator
helm upgrade --install kubernetes-replicator mittwald/kubernetes-replicator
$ # Create roles and service accounts
$ kubectl apply -f https://raw.githubusercontent.com/mittwald/kubernetes-replicator/master/deploy/rbac.yaml
$ # Create actual deployment
$ kubectl apply -f https://raw.githubusercontent.com/mittwald/kubernetes-replicator/master/deploy/deployment.yaml
Push-based replication will "push out" the secrets, configmaps, roles and rolebindings into namespaces when new namespaces are created or when the secret/configmap/roles/rolebindings changes.
To configure a push-based replication, add replicator.v1.mittwald.de/replicate-to
annotation to your
secret, role, or configmap. Value of this annotation should contain a comma separated list of permitted namespaces or regular expressions.
For example namespace-1,my-ns-2,app-ns-[0-9]*
: in this case replication will be performed only into the namespaces namespace-1
and my-ns-2
as well as any namespace that matches the regular expression app-ns-[0-9]*
.
Example:
apiVersion: v1
kind: Secret
metadata:
annotations:
replicator.v1.mittwald.de/replicate-to: "my-ns-1,namespace-[0-9]*"
data:
key1: <value>
Pull-based replication makes it possible to create a secret/configmap/role/rolebindings and select a "source" resource from which the data is replicated from.
If a secret or configMap needs to be replicated to other namespaces, annotations should be added in that object permitting replication.
-
Add
replicator.v1.mittwald.de/replication-allowed
annotation with valuetrue
indicating that the object can be replicated. -
Add
replicator.v1.mittwald.de/replication-allowed-namespaces
annotation. Value of this annotation should contain a comma separated list of permitted namespaces or regular expressions. For examplenamespace-1,my-ns-2,app-ns-[0-9]*
: in this case replication will be performed only into the namespacesnamespace-1
andmy-ns-2
as well as any namespace that matches the regular expressionapp-ns-[0-9]*
.apiVersion: v1 kind: Secret metadata: annotations: replicator.v1.mittwald.de/replication-allowed: "true" replicator.v1.mittwald.de/replication-allowed-namespaces: "my-ns-1,namespace-[0-9]*" data: key1: <value>
Add the annotation replicator.v1.mittwald.de/replicate-from
to any Kubernetes secret or config map object. The value
of that annotation should contain the the name of another secret or config map (using <namespace>/<name>
notation).
apiVersion: v1
kind: Secret
metadata:
name: secret-replica
annotations:
replicator.v1.mittwald.de/replicate-from: default/some-secret
data: {}
The replicator will then copy the data
attribute of the referenced object into the annotated object and keep them in
sync.
Secrets of type kubernetes.io/tls
are treated in a special way and need to have a data["tls.crt"]
and a
data["tls.key"]
property to begin with. In the replicated secrets, these properties need to be present to begin with,
but they may be empty:
apiVersion: v1
kind: Secret
metadata:
name: tls-secret-replica
annotations:
replicator.v1.mittwald.de/replicate-from: default/some-tls-secret
type: kubernetes.io/tls
data:
tls.key: ""
tls.crt: ""
Secrets of type kubernetes.io/dockerconfigjson
also require special treatment. These secrets require to have a
.dockerconfigjson
key that needs to require valid JSON. For this reason, a replicated secret of this type should be
created as follows:
apiVersion: v1
kind: Secret
metadata:
name: docker-secret-replica
annotations:
replicator.v1.mittwald.de/replicate-from: default/some-docker-secret
type: kubernetes.io/dockerconfigjson
data:
.dockerconfigjson: e30K