// the find
mittwald/kubernetes-replicator
Kubernetes controller for synchronizing secrets & config maps across namespaces
A Kubernetes controller that copies Secrets, ConfigMaps, Roles, RoleBindings, and ServiceAccounts across namespaces, since Kubernetes has no native cross-namespace reference for these objects. Useful for anyone managing multi-tenant clusters where a TLS cert, registry credential, or shared config needs to live in more than one namespace without manual copy-paste.
Two distinct replication models — push (annotate the source, target namespaces by name/regex or label selector) and pull (annotate an empty destination object with replicate-from) — cover both 'broadcast this everywhere' and 'this namespace wants that secret' use cases without forcing one pattern. It correctly special-cases resource types that aren't just opaque key-value data: kubernetes.io/tls needs tls.crt/tls.key present, dockerconfigjson needs valid JSON, and both are handled rather than crashing on a generic copy. The strip-labels and keep-owner-references escape hatches show real production hardening — someone hit strimzi-kafka-operator's GC deleting replicated secrets and fixed it, rather than leaving that as a known issue. Label-based push replication also cleans up on unmatch (removes replicated resources when a namespace's labels no longer match), so state doesn't just accumulate stale copies.
Test coverage is uneven — the tree shows tests for role and secret replication but none for configmap.go or serviceaccounts.go, so two of the five supported kinds have no automated safety net. The README doesn't explain what happens if both push and pull annotations end up applying to the same object (e.g. a source object also annotated with replicate-from pointing elsewhere) — that precedence isn't documented and is the kind of thing you find out by breaking prod. Label-based sync silently deleting resources when a namespace's labels change is a sharp edge that isn't called out with a warning — a routine label edit becomes a destructive operation. Nothing in the docs addresses behavior at scale: no mention of rate limiting, backoff, or how it performs when a source object fans out to hundreds of namespaces on every update.