Cert-Manager auf Kubernetes: Vollständige Einrichtungsanleitung für automatisiertes TLS-Zertifikatmanagement

Cert-Manager ist ein Open-Source-Kubernetes-Controller, der den gesamten Lebenszyklus von TLS-Zertifikaten vollständig automatisiert – von der ersten Ausstellung über die Validierung bis hin zur Erneuerung – durch direkte Integration mit Zertifizierungsstellen wie Let’s Encrypt, HashiCorp Vault und privaten PKI-Systemen. Es eliminiert manuelle Zertifikat-Workflows, indem Zertifikate als native Kubernetes-Ressourcen behandelt werden, die deklarativ über Custom Resource Definitions (CRDs) verwaltet werden.

Für jeden produktiven Kubernetes-Cluster sind abgelaufene oder falsch konfigurierte TLS-Zertifikate eine der häufigsten Ursachen für ungeplante Ausfallzeiten. Cert-Manager löst dieses Problem, indem er den Zertifikatsstatus kontinuierlich abgleicht, Anmeldeinformationen automatisch vor dem Ablauf erneuert und das resultierende Schlüsselmaterial in Kubernetes Secrets speichert, die Ingress-Controller und Workloads sofort nutzen können.

Warum Cert-Manager der Standard für Kubernetes TLS-Automatisierung ist

Bevor Cert-Manager zur De-facto-Lösung wurde, haben Teams entweder certbot-Erneuerungen auf einzelnen Knoten geskriptet, Zertifikate manuell über Namespaces rotiert oder sich auf Cloud-Anbieter-spezifische Integrationen verlassen, die zu Vendor-Lock-in führten. Cert-Manager vereint all diese Ansätze unter einer einzigen, Kubernetes-nativen Steuerungsebene.

Wesentliche Vorteile gegenüber Ad-hoc-Ansätzen:

• Deklaratives Management: Die Zertifikatsabsicht wird als YAML-Manifest ausgedrückt, das zusammen mit dem Anwendungscode versioniert wird.
• Automatischer Abgleich: Die Controller-Schleife erkennt Abweichungen zwischen dem gewünschten und dem tatsächlichen Zertifikatsstatus und korrigiert diese ohne menschlichen Eingriff.
• Multi-Issuer-Unterstützung: Ein einzelner Cluster kann gleichzeitig Let’s Encrypt für öffentlich zugängliche Dienste, eine interne CA für Service-Mesh-mTLS und HashiCorp Vault für sicherheitssensible Workloads verwenden.
• Audit-Trail: Jedes CertificateRequest-Objekt wird in der Kubernetes-API gespeichert und gibt Ihnen eine vollständige Ausstellungshistorie.

Der Betrieb von Kubernetes auf einer VPS Hosting-Plattform mit NVMe-gestütztem Speicher und vollem Root-Zugriff gibt Ihnen die notwendige Kontrolle, um benutzerdefinierte DNS-Resolver zu konfigurieren, Firewall-Regeln für ACME HTTP-01-Challenges zu verwalten und Cluster-weite CRDs ohne Einschränkungen zu installieren – alles Voraussetzungen für eine produktionsreife Cert-Manager-Bereitstellung.

Kernarchitektur: Wie Cert-Manager intern funktioniert

Das Verständnis der internen Architektur von Cert-Manager verhindert Fehlkonfigurationen und hilft Ihnen, Ausstellungsfehler schnell zu debuggen.

Der Zertifikatslebenszyklus-Zustandsautomat

Cert-Manager verwaltet Zertifikate durch einen deterministischen Zustandsautomaten. Jede Certificate-Ressource durchläuft die folgenden Zustände:

1. Ausstehend — Das Certificate-Objekt existiert, aber es wurde noch kein gültiges CertificateRequest erfüllt.
2. Ausstellung — Eine CertificateRequest wurde erstellt und an den konfigurierten Issuer übermittelt.
3. Bereit — Ein gültiges, nicht abgelaufenes Zertifikat ist im referenzierten Kubernetes Secret gespeichert.
4. Erneuerung ausstehend — Das Zertifikat befindet sich innerhalb des renewBefore-Fensters (Standard: 30 Tage vor Ablauf) und eine neue CertificateRequest wird verarbeitet.

Der Controller überwacht alle Certificate-Objekte cluster-weit und gleicht deren Status kontinuierlich ab. Wenn ein Secret manuell gelöscht wird, erkennt Cert-Manager die fehlende Ressource und löst sofort eine Neuausstellung aus – ein kritisches selbstheilendes Verhalten, das versehentliche Ausfälle verhindert.

Kern-CRD-Komponenten

Die Order– und Challenge-Ressourcen werden automatisch vom ACME-Issuer erstellt – Sie interagieren selten direkt mit ihnen, aber deren Inspektion ist der primäre Debugging-Pfad, wenn die Ausstellung ins Stocken gerät.

Zertifikatsspeicherung und Secret-Format

Nach der Ausstellung schreibt Cert-Manager drei Datenschlüssel in das Ziel-Kubernetes Secret:

• tls.crt — Die vollständige Zertifikatskette (Blatt + Zwischenzertifikate), PEM-kodiert.
• tls.key — Der private Schlüssel, PEM-kodiert.
• ca.crt — Das ausstellende CA-Zertifikat (für interne CAs befüllt; kann bei ACME-Issuern leer sein).

Ingress-Controller, Service-Meshes und Anwendungs-Pods binden dieses Secret direkt ein. Das Format ist kompatibel mit NGINX, Traefik, Istio, Linkerd und den meisten anderen Kubernetes-nativen TLS-Verbrauchern.

Unterstützte Issuers und wann welcher zu verwenden ist

ACME (Let’s Encrypt und Alternativen)

Das ACME-Protokoll ist der häufigste Ausstellungsweg. Cert-Manager implementiert den vollständigen RFC 8555 ACME-Client und unterstützt sowohl Staging- als auch Produktionsendpunkte.

HTTP-01-Challenge: Cert-Manager stellt vorübergehend ein Token unter http://<domain>/.well-known/acme-challenge/<token> bereit. Dies erfordert, dass die Domain auf eine öffentlich erreichbare IP auf Port 80 auflöst. Es funktioniert für Einzeldomänen- und SAN-Zertifikate, kann jedoch keine Wildcard-Zertifikate ausstellen.

DNS-01-Challenge: Cert-Manager erstellt einen _acme-challenge.<domain> TXT-Eintrag über eine DNS-Anbieter-API. Dies funktioniert hinter Firewalls, unterstützt Wildcard-Zertifikate (*.example.com) und ist für jeden Cluster erforderlich, der nicht direkt mit dem Internet verbunden ist. Unterstützte DNS-Anbieter sind Cloudflare, Route53, Google Cloud DNS, Azure DNS und viele andere über Webhook-Solver.

HashiCorp Vault

Der Vault-Issuer integriert sich mit Vaults PKI-Secrets-Engine. Er ist die bevorzugte Wahl für:

• Internes Microservice-mTLS, bei dem Zertifikate kurzlebig sein müssen (Stunden, nicht Monate).
• Umgebungen mit strengen Schlüsselverwahrungsanforderungen, bei denen private Schlüssel Vault niemals verlassen dürfen.
• Automatisierte Zertifikatsrotation, die an Vaults Lease-Erneuerungssystem gebunden ist.

Self-Signed- und CA-Issuers

Der SelfSigned-Issuer generiert Zertifikate, die mit dem eigenen privaten Schlüssel des Zertifikats signiert sind – nützlich für das Bootstrapping einer Root-CA innerhalb des Clusters. Der CA-Issuer verwendet ein Kubernetes Secret, das ein CA-Schlüsselpaar enthält, um Zertifikate zu signieren, was ihn für interne Entwicklungsumgebungen und Service-Mesh-PKI geeignet macht.

Venafi

Die Venafi-Integration richtet sich an Unternehmensumgebungen mit zentralisierter Zertifikatsrichtlinien-Durchsetzung, Compliance-Auditing und Integration mit Hardware-Sicherheitsmodulen (HSMs).

Cert-Manager vs. alternative TLS-Automatisierungsansätze

Für Teams, die Kubernetes auf einem Dedicated Server oder VPS betreiben, ist Cert-Manager der einzige Ansatz, der gleichzeitig Kubernetes-nativ ist, alle wichtigen CAs unterstützt und keinerlei manuelle Eingriffe erfordert.

Cert-Manager installieren: Produktionsbereites Setup

Voraussetzungen

• Kubernetes 1.22+ (1.26+ empfohlen für vollständige CRD-Stabilität)
• kubectl konfiguriert mit Cluster-Admin-Berechtigungen
• Helm 3.x installiert
• Eine registrierte Domain mit DNS-Verwaltungszugang (für DNS-01) oder eine öffentlich erreichbare Ingress-IP (für HTTP-01)

Wenn Sie Ihre eigene Domain verwalten, wird eine Domain-Registrierung über einen Anbieter, der eine API bereitstellt, dringend empfohlen – dies ermöglicht eine vollständig automatisierte DNS-01-Challenge-Lösung ohne manuelle Eingriffe.

Schritt 1: CRDs und den Cert-Manager-Controller installieren

Die empfohlene Produktionsinstallationsmethode verwendet Helm mit separat verwalteten CRDs, um Helm-Upgrade-Konflikte zu vermeiden:

# Add the Jetstack Helm repository
helm repo add jetstack https://charts.jetstack.io
helm repo update

# Install Cert-Manager with CRDs included
helm install cert-manager jetstack/cert-manager 
  --namespace cert-manager 
  --create-namespace 
  --version v1.14.5 
  --set installCRDs=true 
  --set global.leaderElection.namespace=cert-manager

Überprüfen Sie, ob alle drei Kern-Pods laufen, bevor Sie fortfahren:

kubectl get pods --namespace cert-manager

Erwartete Ausgabe:

NAME                                       READY   STATUS    RESTARTS   AGE
cert-manager-xxxxxxxxx-xxxxx              1/1     Running   0          60s
cert-manager-cainjector-xxxxxxxxx-xxxxx   1/1     Running   0          60s
cert-manager-webhook-xxxxxxxxx-xxxxx      1/1     Running   0          60s

Der cainjector injiziert CA-Bundle-Daten in Webhook-Konfigurationen. Der webhook validiert und mutiert Cert-Manager-CRD-Objekte – wenn er nicht läuft, schlagen alle kubectl apply-Operationen auf Cert-Manager-Ressourcen fehl.

Schritt 2: Einen ClusterIssuer für Let’s Encrypt konfigurieren

Beginnen Sie immer mit der Let’s Encrypt Staging-Umgebung, um Produktions-Rate-Limits zu vermeiden (50 Zertifikate pro registrierter Domain pro Woche):

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: letsencrypt-staging-account-key
    solvers:
      - http01:
          ingress:
            class: nginx

Sobald Staging-Zertifikate erfolgreich ausgestellt werden, erstellen Sie den Produktions-Issuer:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-account-key
    solvers:
      - http01:
          ingress:
            class: nginx

Beide Manifeste anwenden:

kubectl apply -f clusterissuer-staging.yaml
kubectl apply -f clusterissuer-prod.yaml

Issuer-Bereitschaft überprüfen:

kubectl describe clusterissuer letsencrypt-prod

Das Status.Conditions-Feld muss Ready: True anzeigen. Wenn es False anzeigt, ist die ACME-Kontoregistrierung fehlgeschlagen – überprüfen Sie die E-Mail-Adresse und die Netzwerkkonnektivität vom cert-manager-Pod.

Schritt 3: Ein Zertifikat explizit anfordern

Sie können Zertifikate entweder durch direktes Erstellen einer Certificate-Ressource oder durch Annotieren einer Ingress-Ressource anfordern. Der explizite Certificate-Ansatz gibt Ihnen mehr Kontrolle:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com-tls
  namespace: production
spec:
  secretName: example-com-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  commonName: example.com
  dnsNames:
    - example.com
    - www.example.com
  duration: 2160h    # 90 days (Let's Encrypt default)
  renewBefore: 720h  # Renew 30 days before expiry

Anwenden und Ausstellung überwachen:

kubectl apply -f certificate.yaml
kubectl describe certificate example-com-tls -n production

Die CertificateRequest– und Order-Objekte auf detaillierten Status überwachen:

kubectl get certificaterequest -n production
kubectl describe order -n production

Schritt 4: Ingress-Annotationsmethode (vereinfacht)

Für Teams, die den NGINX Ingress Controller verwenden, kann Cert-Manager automatisch über eine Annotation ausgelöst werden – kein separates Certificate-Manifest erforderlich:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example-ingress
  namespace: production
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
spec:
  ingressClassName: nginx
  tls:
    - hosts:
        - example.com
        - www.example.com
      secretName: example-com-tls-secret
  rules:
    - host: example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: example-service
                port:
                  number: 80

Cert-Manager erkennt die Annotation und erstellt automatisch die entsprechende Certificate-Ressource. Dies ist das häufigste Muster in GitOps-Workflows.

Erweiterte Konfigurationsmuster

Wildcard-Zertifikate mit DNS-01 (Cloudflare-Beispiel)

Wildcard-Zertifikate erfordern DNS-01-Validierung. Erstellen Sie zunächst ein Secret, das Ihr Cloudflare-API-Token enthält:

kubectl create secret generic cloudflare-api-token 
  --from-literal=api-token=<YOUR_CLOUDFLARE_API_TOKEN> 
  --namespace cert-manager

Konfigurieren Sie den ClusterIssuer mit einem DNS-01-Solver:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod-dns
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: ops@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-dns-account-key
    solvers:
      - dns01:
          cloudflare:
            apiTokenSecretRef:
              name: cloudflare-api-token
              key: api-token

Das Wildcard-Zertifikat anfordern:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: wildcard-example-com
  namespace: production
spec:
  secretName: wildcard-example-com-tls
  issuerRef:
    name: letsencrypt-prod-dns
    kind: ClusterIssuer
  dnsNames:
    - "*.example.com"
    - example.com

Kritischer Fallstrick: Das Secret, das die DNS-Anbieter-Anmeldeinformationen enthält, muss sich im cert-manager-Namespace befinden, wenn es von einem ClusterIssuer referenziert wird. Wenn Sie es in einem anderen Namespace platzieren, kann der Controller es nicht lesen und die Ausstellung schlägt lautlos fehl. Überprüfen Sie die cert-manager-Controller-Logs mit kubectl logs -n cert-manager deploy/cert-manager, wenn Challenges ins Stocken geraten.

Interne PKI mit einem CA-Issuer

Für Service-zu-Service-mTLS innerhalb eines Clusters ist ein CA-Issuer, der durch eine selbstsignierte Root gesichert ist, geeigneter als ACME:

# Step 1: Create a self-signed root CA certificate
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-root
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: internal-root-ca
  namespace: cert-manager
spec:
  isCA: true
  commonName: internal-root-ca
  secretName: internal-root-ca-secret
  issuerRef:
    name: selfsigned-root
    kind: ClusterIssuer
---
# Step 2: Create a CA issuer backed by the root certificate
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: internal-ca-issuer
spec:
  ca:
    secretName: internal-root-ca-secret

Dienste können nun kurzlebige Zertifikate von internal-ca-issuer für mTLS ohne externe CA-Abhängigkeit anfordern.

renewBefore für hochsichere Umgebungen konfigurieren

Der Standard-renewBefore von 30 Tagen ist für 90-tägige Let’s Encrypt-Zertifikate geeignet. Für kurzlebige interne Zertifikate (z. B. 24-Stunden-Gültigkeit) setzen Sie renewBefore auf einen Bruchteil der Gesamtdauer:

spec:
  duration: 24h
  renewBefore: 8h

Cert-Manager beginnt die Erneuerung 8 Stunden vor dem Ablauf, was dem Controller drei Erneuerungsfenster innerhalb einer 24-stündigen Zertifikatslebensdauer gibt – eine kritische Sicherheitsmarge, wenn der Cluster vorübergehende API-Server-Nichtverfügbarkeit erlebt.

Häufige Cert-Manager-Fehler debuggen

Zertifikat steckt im Zustand „Ausstellung”

# Check the Certificate status
kubectl describe certificate <name> -n <namespace>

# Check the associated CertificateRequest
kubectl describe certificaterequest -n <namespace>

# Check the ACME Order
kubectl describe order -n <namespace>

# Check the Challenge
kubectl describe challenge -n <namespace>

# Check controller logs
kubectl logs -n cert-manager deploy/cert-manager --tail=100

Häufige Grundursachen:

• HTTP-01-Fehler: Der Ingress-Controller leitet /.well-known/acme-challenge/-Traffic nicht korrekt weiter. Überprüfen Sie, ob das Challenge-Ingress-Objekt erstellt wurde und ob Port 80 vom Internet aus erreichbar ist. Firewalls auf dem Host müssen eingehendes TCP/80 erlauben.
• DNS-01-Fehler: Das DNS-Anbieter-API-Token hat unzureichende Berechtigungen, oder die DNS-Propagation ist noch nicht abgeschlossen. Let’s Encrypts Validierungsserver können andere Resolver als Ihr lokales DNS abfragen – Propagationsverzögerungen von 60–120 Sekunden sind normal.
• Rate-Limit überschritten: Let’s Encrypt erzwingt 5 fehlgeschlagene Validierungsversuche pro Domain pro Stunde. Nach Erreichen dieses Limits müssen Sie warten, bevor Sie es erneut versuchen. Testen Sie immer zuerst mit dem Staging-Endpunkt.
• Webhook nicht bereit: Wenn der cert-manager-Webhook-Pod nicht läuft, schlagen alle CRD-Operationen mit einem „Verbindung verweigert”-Fehler fehl. Stellen Sie sicher, dass der Webhook-Dienst einen gültigen Endpunkt hat.

Ein bereitgestelltes Zertifikat überprüfen

# Check the Secret contents
kubectl get secret example-com-tls-secret -n production -o jsonpath='{.data.tls.crt}' | base64 -d | openssl x509 -noout -text

# Check expiry date specifically
kubectl get secret example-com-tls-secret -n production -o jsonpath='{.data.tls.crt}' | base64 -d | openssl x509 -noout -enddate

Checkliste zur Produktionshärtung

Die Bereitstellung von Cert-Manager in einer Produktionsumgebung erfordert mehr als eine Standard-Helm-Installation. Wenden Sie diese Härtungsmaßnahmen an, bevor Sie live gehen:

• Ressourcenlimits: Setzen Sie CPU- und Speicher-requests und limits auf allen drei Cert-Manager-Pods, um Ressourcenkonflikte auf gemeinsam genutzten Knoten zu verhindern.
• RBAC-Audit: Cert-Manager benötigt umfangreiche RBAC-Berechtigungen. Überprüfen Sie die installierten ClusterRole-Objekte und beschränken Sie sie auf das für Ihre Issuer-Typen notwendige Minimum.
• Separater Namespace: Stellen Sie Cert-Manager immer in seinem eigenen cert-manager-Namespace bereit, isoliert von Anwendungs-Workloads.
• Monitoring: Stellen Sie Cert-Managers Prometheus-Metriken-Endpunkt (--metrics-listen-address) bereit und alarmieren Sie bei certmanager_certificate_expiration_timestamp_seconds, um Erneuerungsfehler zu erkennen, bevor sie Dienste beeinträchtigen.
• CRD-Status sichern: Schließen Sie Certificate-, ClusterIssuer– und Issuer-Objekte in Ihre Cluster-Backup-Strategie ein. Der Verlust dieser Manifeste nach einem Disaster-Recovery-Ereignis bedeutet, alle Zertifikatskonfigurationen manuell neu erstellen zu müssen.
• Staging-Validierung: Stellen Sie Ihr erstes Zertifikat niemals gegen einen produktiven ACME-Endpunkt aus. Rate-Limit-Verletzungen können Ihre Domain bis zu einer Woche blockieren.

Wenn Sie mehrere Kubernetes-Cluster betreiben – zum Beispiel zur Trennung von Staging- und Produktions-Workloads – können VPS Control Panels das Cluster-Lifecycle-Management vereinfachen und Ihnen eine einheitliche Oberfläche für die Bereitstellung der zugrunde liegenden Infrastruktur bieten, auf der jeder Cluster läuft.

Für Workloads, die GPU-beschleunigte Inferenz oder ML-Serving hinter TLS-terminierten Endpunkten erfordern, gelten dieselben Cert-Manager-Muster auf GPU Hosting-Infrastruktur, wo automatisiertes Zertifikatsmanagement für die Sicherung von Modell-API-Endpunkten gleichermaßen kritisch ist.

Praktische Entscheidungsmatrix: Den richtigen Issuer wählen

Wichtigste Erkenntnisse

• Installieren Sie Cert-Manager mit Helm mit installCRDs=true und validieren Sie immer gegen den Staging-ACME-Endpunkt, bevor Sie auf Produktion umschalten.
• Verwenden Sie ClusterIssuer für Multi-Namespace-Cluster; verwenden Sie namespace-scoped Issuer nur, wenn Sie CA-Isolation pro Team benötigen.
• DNS-01 ist zwingend erforderlich für Wildcard-Zertifikate und für Cluster, die nicht direkt vom Internet auf Port 80 erreichbar sind.
• Das renewBefore-Feld ist in der Produktion nicht optional – setzen Sie es auf mindestens ein Drittel der gesamten duration des Zertifikats.
• Wenn die Ausstellung ins Stocken gerät, ist der Debugging-Pfad immer: Certificate → CertificateRequest → Order → Challenge → Controller-Logs.
• DNS-Anbieter-API-Anmeldeinformationen, die von einem ClusterIssuer referenziert werden, müssen im cert-manager-Namespace liegen, nicht in Anwendungs-Namespaces.
• Überwachen Sie certmanager_certificate_expiration_timestamp_seconds in Prometheus und alarmieren Sie darauf – stille Erneuerungsfehler sind der gefährlichste Fehlermodus.
• Sichern Sie Ihre Certificate– und ClusterIssuer-Manifeste als Teil Ihres Disaster-Recovery-Plans.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem Issuer und einem ClusterIssuer in Cert-Manager?

Ein Issuer ist namespace-scoped und kann nur Zertifikate innerhalb des Namespace ausstellen, in dem er definiert ist. Ein ClusterIssuer ist cluster-weit und kann von Certificate-Ressourcen in jedem Namespace referenziert werden. Für die meisten Produktionscluster ist ClusterIssuer die richtige Wahl, es sei denn, Sie benötigen eine strikte CA-Isolation auf Namespace-Ebene.

Warum steckt mein Cert-Manager-Zertifikat im Zustand „Ausstellung”?

Untersuchen Sie die Order– und Challenge-Objekte im selben Namespace mit kubectl describe. Die häufigsten Ursachen sind: Port 80 durch eine Firewall blockiert (HTTP-01), falsche DNS-API-Anmeldeinformationen oder Propagationsverzögerung (DNS-01), Let’s Encrypt-Rate-Limits überschritten oder der cert-manager-Webhook-Pod läuft nicht. Überprüfen Sie immer die Controller-Logs mit kubectl logs -n cert-manager deploy/cert-manager.

Kann Cert-Manager Wildcard-Zertifikate von Let’s Encrypt ausstellen?

Ja, aber nur mit dem DNS-01-Challenge-Typ. HTTP-01 kann keine Wildcard-Domains validieren. Sie müssen eine DNS-Anbieter-Integration (Cloudflare, Route53 usw.) in Ihrer ClusterIssuer-Solver-Konfiguration einrichten und sicherstellen, dass die API-Anmeldeinformationen die Berechtigung haben, TXT-Einträge auf der Zieldomain zu erstellen.

Wie handhabt Cert-Manager die automatische Zertifikatserneuerung?

Cert-Managers Controller vergleicht kontinuierlich den Ablauf jedes Certificate-Objekts mit der aktuellen Zeit. Wenn die verbleibende Gültigkeit unter den renewBefore-Schwellenwert fällt (Standard: 30 Tage), erstellt der Controller eine neue CertificateRequest, schließt die ACME-Challenge ab und ersetzt atomisch den Inhalt des Ziel-Secret – alles ohne Neustart der Pods, die das Zertifikat verwenden. Pods, die das Secret als Volume einbinden, sehen das aktualisierte Zertifikat beim nächsten kubelet-Sync-Zyklus.

Ist Cert-Manager für die Absicherung interner Service-zu-Service-Kommunikation geeignet, nicht nur für öffentliches HTTPS?

Ja. Mit dem CA-Issuer oder dem HashiCorp Vault-Issuer kann Cert-Manager kurzlebige Zertifikate für internes mTLS zwischen Microservices ausstellen. Dies ist ein häufiges Muster in Service-Mesh-Deployments, bei denen jede Workload ein eindeutiges Identitätszertifikat benötigt. Die duration– und renewBefore-Felder ermöglichen Zertifikate mit einer Lebensdauer von nur wenigen Minuten, mit vollständig automatisierter Rotation.