From Manual TLS Certificate Management to Automatic Rotation in Kubernetes Using cert-manager and Reflector

One of the recurring operational challenges in Kubernetes is managing TLS certificates across multiple namespaces. As clusters grow and applications become more distributed, manually copying renewed certificates between namespaces quickly becomes error-prone and difficult to maintain.

Recently, we solved this problem in our production Kubernetes environment by combining cert-manager with Reflector, creating a fully automated certificate propagation workflow.

The Problem

Our environment hosts multiple applications across different Kubernetes namespaces, all using the same wildcard TLS certificate.

The certificate was issued and renewed by cert-manager, but the consuming applications existed in different namespaces.

Initially, every certificate renewal required manual intervention:

• Wait for cert-manager to renew the certificate
• Export the updated Kubernetes Secret
• Copy it to multiple namespaces
• Restart affected workloads if necessary
• Verify every ingress was using the latest certificate

While manageable initially, this approach became an operational burden as the platform expanded.

The challenges included:

• Manual operational overhead
• Risk of expired certificates
• Configuration drift between namespaces
• Potential production outages due to missed updates

Understanding the Root Cause

cert-manager intentionally stores certificates only in the namespace where the Certificate resource exists.

Kubernetes Secrets are namespace-scoped, meaning they cannot be directly shared across namespaces.

Although every application required the same wildcard certificate, Kubernetes isolation prevented a single Secret from being reused.

The Solution

Instead of writing custom synchronization scripts or CronJobs, we adopted Reflector.

The architecture became:

Let's Encrypt
        │
        ▼
 cert-manager
        │
Renews Wildcard Certificate
        │
Creates Kubernetes Secret
        │
        ▼
Reflector watches Secret updates
        │
Automatically copies Secret
        │
        ▼
Application Namespaces
        │
Ingress Controllers immediately use
the renewed certificate

Now the entire certificate lifecycle is automatic.

How It Works

1. cert-manager monitors certificate expiry.
2. Before expiration, it automatically requests a new certificate.
3. The Kubernetes Secret is updated.
4. Reflector detects the Secret change.
5. Reflector synchronizes the Secret to every configured namespace.
6. Ingress controllers automatically begin serving the new certificate.

No manual intervention.

No downtime.

No copy scripts.

Benefits

After implementing this approach we achieved:

• Fully automated wildcard certificate renewal
• Automatic Secret propagation across namespaces
• Elimination of manual certificate synchronization
• Reduced operational overhead
• Lower risk of certificate expiry incidents
• Consistent TLS configuration across all applications
• Improved production reliability

Why Reflector Instead of Custom Scripts?

Many organizations solve this problem using:

• CronJobs
• Bash scripts
• CI/CD pipelines
• Kubernetes Jobs

Although these methods work, they introduce additional maintenance and operational complexity.

Reflector is Kubernetes-native.

It continuously watches Secrets and automatically mirrors changes without requiring custom automation.

This significantly simplifies certificate management.

Key Takeaways

Infrastructure automation isn’t only about deployments.

Removing repetitive operational tasks is equally valuable.

By combining cert-manager with Reflector, we transformed certificate renewal from a manual maintenance activity into a fully automated, self-healing process.

Small platform improvements like this reduce operational risk, save engineering time, and improve production reliability over the long term.

Tech Stack

• Kubernetes
• cert-manager
• Reflector
• NGINX Ingress Controller
• Let’s Encrypt
• TLS / PKI

If you’re managing Kubernetes environments with shared TLS certificates across multiple namespaces, I’d love to hear how you’ve approached certificate distribution and rotation.

Kubernetes #DevOps #SRE #PlatformEngineering #CloudNative #certmanager #TLS #LetsEncrypt #KubernetesSecurity #Automation #GKE #InfrastructureAsCode