Proposal: "Pull-based" Replication Using Service Account for Kubernetes-Replicator

[thesn10]

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:

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:

apiVersion: v1
kind: Secret
metadata:
  name: secret-replica
  annotations:
    replicator.v1.mittwald.de/replicate-from: secret-reader-namespace/some-secret
    replicator.v1.mittwald.de/service-account: my-service-account
data: {}

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.