Cert-Manager: Die Referenz-Architektur für automatisiertes Zertifikats-Management in Kubernetes
Fabian Peter 5 Minuten Lesezeit

Cert-Manager: Die Referenz-Architektur für automatisiertes Zertifikats-Management in Kubernetes

Verschlüsselung ist Pflicht, aber ihre Verwaltung oft ein Albtraum. Während AWS Certificate Manager (ACM) zwar kostenlose Zertifikate bietet, diese aber technisch an die AWS-Infrastruktur kettet (kein Key-Export), etabliert der cert-manager einen offenen Standard. Er automatisiert die Ausstellung, Erneuerung und Nutzung von Zertifikaten über Kubernetes CRDs. Dies garantiert, dass die kryptografische Identität Ihrer Anwendungen portabel bleibt und Ihnen gehört – nicht dem Cloud-Provider.
cert-manager kubernetes tls-zertifikate infrastructure-as-code automatisierung datenhoheit cloud-provider

TL;DR

Verschlüsselung ist Pflicht, aber ihre Verwaltung oft ein Albtraum. Während AWS Certificate Manager (ACM) zwar kostenlose Zertifikate bietet, diese aber technisch an die AWS-Infrastruktur kettet (kein Key-Export), etabliert der cert-manager einen offenen Standard. Er automatisiert die Ausstellung, Erneuerung und Nutzung von Zertifikaten über Kubernetes. Dies garantiert, dass die kryptografische Identität Ihrer Anwendungen portabel bleibt und Ihnen gehört – nicht dem Cloud-Provider.

1. Das Architektur-Prinzip: Infrastructure as Code für TLS

In klassischen Umgebungen werden Zertifikate oft manuell beantragt, per E-Mail empfangen und händisch auf Server kopiert. Das ist in dynamischen Container -Umgebungen nicht skalierbar.

Der cert-manager läuft als Controller im Kubernetes-Cluster und implementiert Zertifikate als native Ressource (Kind: Certificate).

  1. Deklarative Definition: Sie definieren in einer YAML-Datei, dass eine Domain (z.B. api.example.com) ein Zertifikat benötigt und wer der Aussteller ist (z.B. Let’s Encrypt).
  2. Automatisierung: Der Controller überwacht diese Ressourcen. Läuft ein Zertifikat bald ab, kümmert sich der cert-manager eigenständig um die Erneuerung (Renewal) und aktualisiert das entsprechende Kubernetes Secret. Die Applikation (oder der Ingress Controller) lädt das neue Zertifikat automatisch neu.

2. Kern-Feature: Echte Datenhoheit über Private Keys

Der entscheidende Unterschied zu Managed Services liegt in der Kryptografie. Ein TLS-Zertifikat besteht aus dem öffentlichen Teil (Public Key) und dem privaten Schlüssel (Private Key).

Beim cert-manager werden beide Teile als standardisiertes Kubernetes Secret (type: kubernetes.io/tls) in Ihrem Namensraum gespeichert.

  • Vollzugriff: Sie haben physischen Zugriff auf den Private Key. Das bedeutet, Sie können das Zertifikat exportieren, in Backups sichern oder auf eine andere Infrastruktur migrieren.
  • Flexibilität: Da das Zertifikat als Secret vorliegt, kann es nicht nur am Ingress (LoadBalancer), sondern auch innerhalb des Clusters für Service-zu-Service-Verschlüsselung (mTLS) genutzt werden.

3. ACME und DNS-01 Validierung

Der cert-manager beherrscht das ACME-Protokoll (Automated Certificate Management Environment). Dies ermöglicht die nahtlose Integration mit öffentlichen CAs wie Let’s Encrypt oder ZeroSSL. Besonders mächtig ist die DNS-01 Challenge: Der cert-manager kann temporäre DNS-Einträge setzen, um den Besitz einer Domain zu beweisen. Dies ermöglicht die Ausstellung von Wildcard-Zertifikaten (*.example.com) und Zertifikaten für interne Dienste, die nicht öffentlich aus dem Internet erreichbar sind.

4. Betriebsmodelle im Vergleich: AWS ACM vs. ayedo Managed cert-manager

Hier entscheidet sich, ob Ihre Sicherheitsarchitektur portabel ist oder ob Sie sich kryptografisch an Amazon binden.

Szenario A: AWS Certificate Manager / ACM (Der goldene Käfig)

ACM wirkt auf den ersten Blick verlockend: Kostenlose öffentliche Zertifikate. Doch der Preis ist die technische Unmündigkeit.

  • Kein Key-Export: AWS gibt die Private Keys von öffentlichen ACM-Zertifikaten niemals heraus. Sie können diese Zertifikate nur auf AWS LoadBalancern (ALB/NLB) oder CloudFront nutzen.
  • Keine Cluster-Nutzung: Sie können ACM-Zertifikate nicht direkt in einen Kubernetes-Pod mounten. Eine Ende-zu-Ende-Verschlüsselung bis zum Container ist mit öffentlichen ACM-Zertifikaten nicht möglich.
  • Das Resultat: Ihre Zertifikate gehören AWS. Wenn Sie zu Azure oder On-Prem wechseln wollen, müssen Sie alle Zertifikate neu ausstellen und validieren lassen. Es gibt keinen Migrationspfad.

Szenario B: cert-manager mit Managed Kubernetes von ayedo

Im ayedo App-Katalog ist der cert-manager der Standard für TLS.

  • Volle Kontrolle: Zertifikate liegen als Secrets im Cluster. Ein Umzug zu einem anderen Provider bedeutet lediglich: Backup einspielen (z.B. mit Velero) und weiterarbeiten.
  • Provider-Unabhängigkeit: Ob Let’s Encrypt, eine eigene Firmen-CA (via Vault) oder Google CAS – der cert-manager abstrahiert den Anbieter. Sie tauschen im Hintergrund den ClusterIssuer aus, ohne dass die Entwickler ihre Applikations-Manifeste ändern müssen.
  • Standard-Ingress: Die Integration funktioniert nativ mit dem Nginx Ingress Controller, ohne proprietäre AWS-Annotationen.

Technischer Vergleich der Betriebsmodelle

Aspekt AWS ACM (Proprietär) ayedo (Managed cert-manager)
Private Key Besitz Nein (Verwaltet von AWS) Ja (Kubernetes Secret)
Exportierbarkeit Unmöglich (für öffentliche Certs) Vollständig möglich
Nutzungsort Nur AWS LB / CloudFront Überall (Ingress, Pods, Mesh)
Wildcards Ja (nur via DNS-Validierung) Ja (via DNS-01 ACME)
Kosten Kostenlos (aber Lock-in) Kostenlos (Let’s Encrypt)
Strategisches Risiko Hoher Lock-in (Neu-Ausstellung bei Wechsel) Volle Souveränität

FAQ: cert-manager & TLS Strategy

Warum sollte ich cert-manager nutzen, wenn ACM kostenlos ist?

Wegen der Portabilität und der “Data Plane Encryption”. ACM zwingt Sie, die SSL-Terminierung am AWS LoadBalancer zu machen. Der Traffic fließt danach oft unverschlüsselt durch das VPC zum Pod. Mit dem cert-manager können Sie die Verschlüsselung bis direkt in den Pod (Nginx/App) führen oder Zertifikate für Service-Meshes (Istio/Linkerd) bereitstellen. Zudem gehört die kryptografische Identität Ihnen, nicht AWS.

Was passiert, wenn Let’s Encrypt Ratenlimits erreicht?

In Produktionsumgebungen konfiguriert ayedo den cert-manager so, dass er robust läuft. Für Entwicklungs-Cluster wird das “Staging”-Environment von Let’s Encrypt genutzt, um Limits nicht zu verbrauchen. Zudem können Fallback-Issuer (z.B. ZeroSSL) konfiguriert werden, um Redundanz zu schaffen.

Kann ich auch Zertifikate für interne Domains (.local) ausstellen?

Ja. Der cert-manager kann nicht nur mit öffentlichen CAs sprechen, sondern auch als eigene CA fungieren (CA Issuer) oder sich mit HashiCorp Vault verbinden. So können Sie vollautomatisiert Zertifikate für interne Microservices ausstellen, denen Ihre interne Infrastruktur vertraut.

Muss ich DNS-Provider-Zugangsdaten im Cluster speichern?

Für die DNS-01 Challenge (nötig für Wildcards) benötigt der cert-manager API-Zugriff auf Ihr DNS (z.B. Route53 oder Cloudflare). Im ayedo Stack wird dies sicher gelöst: Zugangsdaten werden als verschlüsselte Secrets hinterlegt oder (bei AWS) über IAM Roles for Service Accounts (IRSA) gelöst, sodass keine statischen Access Keys im Cluster liegen müssen.

Fazit

Verschlüsselung ist das Fundament von Zero Trust. Wer dieses Fundament auf dem AWS Certificate Manager (ACM) baut, zementiert eine harte Abhängigkeit zur AWS-Plattform, da Zertifikate nicht exportiert werden können. Der cert-manager hingegen demokratisiert TLS. Er macht Zertifikate zu einer portablen Ressource, die der Nutzer kontrolliert. Mit dem ayedo Managed Stack erhalten Unternehmen eine robuste, vollautomatisierte PKI (Public Key Infrastructure), die auf offenen Standards basiert und maximale Freiheit für die Zukunft garantiert.

Ähnliche Artikel