Cert-Manager: The Reference Architecture for Automated Certificate Management in Kubernetes
Fabian Peter 5 Minuten Lesezeit

Cert-Manager: The Reference Architecture for Automated Certificate Management in Kubernetes

Encryption is mandatory, but managing it is often a nightmare. While AWS Certificate Manager (ACM) offers free certificates, they are technically tied to the AWS infrastructure (no key export). Cert-manager establishes an open standard, automating the issuance, renewal, and use of certificates via Kubernetes CRDs. This ensures that the cryptographic identity of your applications remains portable and belongs to you—not the cloud provider.
cert-manager kubernetes tls-zertifikate infrastructure-as-code automatisierung datenhoheit cloud-provider

TL;DR

Encryption is mandatory, but managing it is often a nightmare. While AWS Certificate Manager (ACM) offers free certificates, they are technically tied to the AWS infrastructure (no key export). Cert-manager establishes an open standard, automating the issuance, renewal, and use of certificates via Kubernetes. This ensures that the cryptographic identity of your applications remains portable and belongs to you—not the cloud provider.

1. The Architectural Principle: Infrastructure as Code for TLS

In traditional environments, certificates are often requested manually, received via email, and manually copied to servers. This is not scalable in dynamic Container environments.

The cert-manager runs as a controller in the Kubernetes cluster and implements certificates as a native resource (Kind: Certificate).

  1. Declarative Definition: You define in a YAML file that a domain (e.g., api.example.com) requires a certificate and who the issuer is (e.g., Let’s Encrypt).
  2. Automation: The controller monitors these resources. If a certificate is about to expire, cert-manager independently handles the renewal and updates the corresponding Kubernetes Secret. The application (or the Ingress Controller) automatically reloads the new certificate.

2. Core Feature: True Data Sovereignty over Private Keys

The key difference from managed services lies in cryptography. A TLS certificate consists of the public part (Public Key) and the private key (Private Key).

With cert-manager, both parts are stored as a standardized Kubernetes Secret (type: kubernetes.io/tls) in your namespace.

  • Full Access: You have physical access to the Private Key. This means you can export the certificate, secure it in backups, or migrate it to another infrastructure.
  • Flexibility: Since the certificate is available as a Secret, it can be used not only at the Ingress (LoadBalancer) but also within the cluster for service-to-service encryption (mTLS).

3. ACME and DNS-01 Validation

Cert-manager supports the ACME protocol (Automated Certificate Management Environment). This enables seamless integration with public CAs like Let’s Encrypt or ZeroSSL. Particularly powerful is the DNS-01 Challenge: Cert-manager can set temporary DNS entries to prove domain ownership. This allows the issuance of Wildcard Certificates (*.example.com) and certificates for internal services that are not publicly accessible from the internet.

4. Operating Models Compared: AWS ACM vs. ayedo Managed cert-manager

Here, it is decided whether your security architecture is portable or if you are cryptographically tied to Amazon.

Scenario A: AWS Certificate Manager / ACM (The Golden Cage)

ACM seems tempting at first glance: free public certificates. But the price is technical dependence.

  • No Key Export: AWS never releases the Private Keys of public ACM certificates. You can use these certificates only on AWS LoadBalancers (ALB/NLB) or CloudFront.
  • No Cluster Usage: You cannot directly mount ACM certificates into a Kubernetes Pod. End-to-end encryption to the Container is not possible with public ACM certificates.
  • The Result: Your certificates belong to AWS. If you want to switch to Azure or on-premises, you must reissue and validate all certificates. There is no migration path.

Scenario B: cert-manager with Managed Kubernetes from ayedo

In the ayedo App Catalog, cert-manager is the standard for TLS.

  • Full Control: Certificates are stored as Secrets in the cluster. Moving to another provider simply means: restore from backup (e.g., with Velero) and continue working.
  • Provider Independence: Whether Let’s Encrypt, your own company CA (via Vault), or Google CAS—the cert-manager abstracts the provider. You swap the ClusterIssuer in the background without developers needing to change their application manifests.
  • Standard Ingress: Integration works natively with the Nginx Ingress Controller, without proprietary AWS annotations.

Technical Comparison of Operating Models

Aspect AWS ACM (Proprietary) ayedo (Managed cert-manager)
Private Key Ownership No (Managed by AWS) Yes (Kubernetes Secret)
Exportability Impossible (for public certs) Fully possible
Usage Location Only AWS LB / CloudFront Anywhere (Ingress, Pods, Mesh)
Wildcards Yes (only via DNS validation) Yes (via DNS-01 ACME)
Cost Free (but lock-in) Free (Let’s Encrypt)
Strategic Risk High Lock-in (Re-issuance on switch) Full Sovereignty

FAQ: cert-manager & TLS Strategy

Why should I use cert-manager if ACM is free?

Because of portability and “Data Plane Encryption.” ACM forces you to do SSL termination at the AWS LoadBalancer. The traffic often flows unencrypted through the VPC to the Pod. With cert-manager, you can extend encryption directly into the Pod (Nginx/App) or provide certificates for service meshes (Istio/Linkerd). Moreover, the cryptographic identity belongs to you, not AWS.

What happens if Let’s Encrypt rate limits are reached?

In production environments, ayedo configures cert-manager to run robustly. For development clusters, Let’s Encrypt’s “Staging” environment is used to avoid consuming limits. Additionally, fallback issuers (e.g., ZeroSSL) can be configured to create redundancy.

Can I issue certificates for internal domains (.local)?

Yes. Cert-manager can not only communicate with public CAs but also function as its own CA (CA Issuer) or connect with HashiCorp Vault. This allows you to fully automate the issuance of certificates for internal microservices that your internal infrastructure trusts.

Do I need to store DNS provider credentials in the cluster?

For the DNS-01 Challenge (necessary for wildcards), cert-manager requires API access to your DNS (e.g., Route53 or Cloudflare). In the ayedo stack, this is securely solved: credentials are stored as encrypted Secrets or (in AWS) resolved via IAM Roles for Service Accounts (IRSA), so no static access keys need to be in the cluster.

Conclusion

Encryption is the foundation of Zero Trust. Building this foundation on AWS Certificate Manager (ACM) cements a hard dependency on the AWS platform, as certificates cannot be exported. Cert-manager, on the other hand, democratizes TLS. It makes certificates a portable resource controlled by the user. With the ayedo Managed Stack, companies receive a robust, fully automated PKI (Public Key Infrastructure) based on open standards, guaranteeing maximum freedom for the future.

Ähnliche Artikel