Kubernetes-Replicator is an operator designed to replicate secrets, config maps, roles, and role bindings across namespaces. The existing "Pull-based" replication feature relies on annotations to specify the source resource to replicate from. However, there are scenarios where annotating the source secret is not feasible, such as when dealing with automatically generated secrets like those generated by operators or certificate secrets produced by cert-manager.
This proposal introduces a new feature to Kubernetes-Replicator, allowing users to specify a service account with appropriate permissions to access the source secret, enabling replication without the need for annotations on each secret.
Summary
The "Pull-based" replication using service account feature simplifies the replication process by decoupling the replication source from annotations. Users can create a service account with the necessary permissions to access the source secret, eliminating the need to manually annotate each secret or config map. Here's a step-by-step guide on how to utilize this feature:
Step 1: Create Service Account and Grant Permissions
Start by defining a service account and configuring its permissions to access the source secret. Below is an example YAML configuration:
apiVersion: v1
kind: ServiceAccount
metadata:
name: my-service-account
namespace: secret-reader-namespace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: secret-reader-role
namespace: secret-owner-namespace
rules:
- apiGroups: [""]
resources: ["secrets"]
resourceNames: ["some-secret"]
verbs: ["get", "watch", "list"]
---
# Allow pods in the 'secret-reader-namespace' to read 'some-secret'
# by binding the default ServiceAccount of 'secret-reader-namespace'
# to the Role of 'secret-reader-role'.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: secret-reader-rolebinding
namespace: secret-owner-namespace
subjects:
- kind: ServiceAccount
name: my-service-account
apiGroup: ""
namespace: secret-reader-namespace
roleRef:
kind: Role
name: secret-reader-role
apiGroup: rbac.authorization.k8s.io
This configuration sets up a service account (my-service-account) in the secret-reader-namespace with permissions to access the some-secret resource in the secret-owner-namespace.
Step 2: Create an Empty Destination Secret
To initiate replication using the service account, create an empty destination secret or config map and add two specific annotations to it:
replicator.v1.mittwald.de/replicate-from: Specifies the source secret or config map to replicate from, using the <namespace>/<name> notation.
replicator.v1.mittwald.de/service-account: Identifies the service account authorized to access the source secret.
Here's an example YAML configuration for the destination secret:
Kubernetes-Replicator will then copy the data attribute from the referenced source object (secret-reader-namespace/some-secret) into the annotated destination object (secret-replica) and keep them in sync.
With this feature, Kubernetes-Replicator provides a more flexible and dynamic approach to secret replication, ensuring that secrets are replicated reliably and efficiently across namespaces, even in scenarios where manual annotations are not suitable.
I am excited to hear your opinions about this poposal.
Introduction
Kubernetes-Replicator is an operator designed to replicate secrets, config maps, roles, and role bindings across namespaces. The existing "Pull-based" replication feature relies on annotations to specify the source resource to replicate from. However, there are scenarios where annotating the source secret is not feasible, such as when dealing with automatically generated secrets like those generated by operators or certificate secrets produced by cert-manager.
This proposal introduces a new feature to Kubernetes-Replicator, allowing users to specify a service account with appropriate permissions to access the source secret, enabling replication without the need for annotations on each secret.
Summary
The "Pull-based" replication using service account feature simplifies the replication process by decoupling the replication source from annotations. Users can create a service account with the necessary permissions to access the source secret, eliminating the need to manually annotate each secret or config map. Here's a step-by-step guide on how to utilize this feature:
Step 1: Create Service Account and Grant Permissions
Start by defining a service account and configuring its permissions to access the source secret. Below is an example YAML configuration:
This configuration sets up a service account (
my-service-account
) in thesecret-reader-namespace
with permissions to access thesome-secret
resource in thesecret-owner-namespace
.Step 2: Create an Empty Destination Secret
To initiate replication using the service account, create an empty destination secret or config map and add two specific annotations to it:
replicator.v1.mittwald.de/replicate-from
: Specifies the source secret or config map to replicate from, using the<namespace>/<name>
notation.replicator.v1.mittwald.de/service-account
: Identifies the service account authorized to access the source secret.Here's an example YAML configuration for the destination secret:
Kubernetes-Replicator will then copy the
data
attribute from the referenced source object (secret-reader-namespace/some-secret
) into the annotated destination object (secret-replica
) and keep them in sync.With this feature, Kubernetes-Replicator provides a more flexible and dynamic approach to secret replication, ensuring that secrets are replicated reliably and efficiently across namespaces, even in scenarios where manual annotations are not suitable.
I am excited to hear your opinions about this poposal.