Cert-Manager na Kubernetes: Kompletny przewodnik konfiguracji automatycznego zarządzania certyfikatami TLS

Cert-Manager to otwartoźródłowy kontroler Kubernetes, który w pełni automatyzuje cykl życia certyfikatów TLS — od początkowego wystawiania przez walidację i odnawianie — poprzez bezpośrednią integrację z urzędami certyfikacji, takimi jak Let’s Encrypt, HashiCorp Vault i prywatne systemy PKI. Eliminuje ręczne procesy obsługi certyfikatów, traktując certyfikaty jako natywne zasoby Kubernetes, zarządzane deklaratywnie za pomocą Custom Resource Definitions (CRDs).

W każdym produkcyjnym klastrze Kubernetes wygasłe lub błędnie skonfigurowane certyfikaty TLS są jedną z najczęstszych przyczyn nieplanowanych przestojów. Cert-Manager rozwiązuje ten problem poprzez ciągłe uzgadnianie stanu certyfikatów, automatyczne odnawianie poświadczeń przed wygaśnięciem oraz przechowywanie wynikowego materiału kluczowego w Kubernetes Secrets, które kontrolery Ingress i obciążenia robocze mogą natychmiast wykorzystywać.

Dlaczego Cert-Manager jest standardem automatyzacji TLS w Kubernetes

Zanim Cert-Manager stał się rozwiązaniem de facto, zespoły albo skryptowały odnawianie certbot na poszczególnych węzłach, ręcznie rotowały certyfikaty między przestrzeniami nazw, albo polegały na integracjach specyficznych dla dostawców chmury, które tworzyły uzależnienie od dostawcy. Cert-Manager ujednolica wszystkie te podejścia w ramach jednej, natywnej dla Kubernetes płaszczyzny sterowania.

Kluczowe zalety w porównaniu z podejściami ad-hoc:

• Zarządzanie deklaratywne: Intencja dotycząca certyfikatu jest wyrażona jako manifest YAML, wersjonowany razem z kodem aplikacji.
• Automatyczne uzgadnianie: Pętla kontrolera wykrywa rozbieżności między pożądanym a rzeczywistym stanem certyfikatu i koryguje je bez udziału człowieka.
• Obsługa wielu wystawców: Pojedynczy klaster może jednocześnie używać Let’s Encrypt dla usług publicznych, wewnętrznego CA dla mTLS siatki usług oraz HashiCorp Vault dla obciążeń wrażliwych na sekrety.
• Ścieżka audytu: Każdy obiekt CertificateRequest jest utrwalany w API Kubernetes, zapewniając kompletną historię wystawiania.

Uruchamianie Kubernetes na platformie VPS Hosting z pamięcią masową opartą na NVMe i pełnym dostępem root daje kontrolę niezbędną do konfigurowania niestandardowych resolverów DNS, zarządzania regułami zapory sieciowej dla wyzwań ACME HTTP-01 oraz instalowania CRDs na poziomie klastra bez ograniczeń — wszystkie te elementy są warunkami wstępnymi dla produkcyjnego wdrożenia Cert-Manager.

Podstawowa architektura: jak Cert-Manager działa wewnętrznie

Zrozumienie wewnętrznej architektury Cert-Manager zapobiega błędom konfiguracji i pomaga szybko debugować błędy wystawiania.

Maszyna stanów cyklu życia certyfikatu

Cert-Manager zarządza certyfikatami za pomocą deterministycznej maszyny stanów. Każdy zasób Certificate przechodzi przez następujące stany:

1. Oczekujący — Obiekt Certificate istnieje, ale żaden prawidłowy CertificateRequest nie został zrealizowany.
2. Wystawianie — Obiekt CertificateRequest został utworzony i przesłany do skonfigurowanego wystawcy.
3. Gotowy — Prawidłowy, niewyg asły certyfikat jest przechowywany w przywoływanym Kubernetes Secret.
4. Oczekiwanie na odnowienie — Certyfikat znajduje się w oknie renewBefore (domyślnie: 30 dni przed wygaśnięciem) i nowy CertificateRequest jest przetwarzany.

Kontroler obserwuje wszystkie obiekty Certificate w całym klastrze i stale uzgadnia ich stan. Jeśli Secret zostanie ręcznie usunięty, Cert-Manager wykrywa brakujący zasób i natychmiast wyzwala ponowne wystawienie — krytyczne zachowanie samoleczące, które zapobiega przypadkowym awariom.

Podstawowe komponenty CRD

Zasoby Order i Challenge są tworzone automatycznie przez wystawcę ACME — rzadko wchodzisz z nimi w bezpośrednią interakcję, ale ich inspekcja jest podstawową ścieżką debugowania, gdy wystawianie się zatrzymuje.

Przechowywanie certyfikatów i format Secret

Po wystawieniu Cert-Manager zapisuje trzy klucze danych w docelowym Kubernetes Secret:

• tls.crt — Pełny łańcuch certyfikatów (liść + pośrednie), zakodowany w PEM.
• tls.key — Klucz prywatny, zakodowany w PEM.
• ca.crt — Certyfikat wystawiającego CA (wypełniany dla wewnętrznych CA; może być pusty dla wystawców ACME).

Kontrolery Ingress, siatki usług i pody aplikacji montują ten Secret bezpośrednio. Format jest kompatybilny z NGINX, Traefik, Istio, Linkerd i większością innych natywnych dla Kubernetes konsumentów TLS.

Obsługiwani wystawcy i kiedy używać każdego z nich

ACME (Let’s Encrypt i alternatywy)

Protokół ACME jest najczęstszą ścieżką wystawiania. Cert-Manager implementuje pełnego klienta ACME zgodnego z RFC 8555, obsługując zarówno środowiska testowe, jak i produkcyjne.

Wyzwanie HTTP-01: Cert-Manager tymczasowo serwuje token pod adresem http://<domain>/.well-known/acme-challenge/<token>. Wymaga to, aby domena rozwiązywała się na publicznie dostępny adres IP na porcie 80. Działa dla certyfikatów z jedną domeną i SAN, ale nie może wystawiać certyfikatów wildcard.

Wyzwanie DNS-01: Cert-Manager tworzy rekord TXT _acme-challenge.<domain> za pośrednictwem API dostawcy DNS. Działa za zaporami sieciowymi, obsługuje certyfikaty wildcard (*.example.com) i jest wymagane dla każdego klastra niewystawionego bezpośrednio na internet. Obsługiwani dostawcy DNS to Cloudflare, Route53, Google Cloud DNS, Azure DNS i wielu innych za pośrednictwem solverów webhook.

HashiCorp Vault

Wystawca Vault integruje się z silnikiem sekretów PKI Vault. Jest preferowanym wyborem dla:

• Wewnętrznego mTLS mikroserwisów, gdzie certyfikaty muszą być krótkotrwałe (godziny, nie miesiące).
• Środowisk z rygorystycznymi wymaganiami dotyczącymi przechowywania kluczy, gdzie klucze prywatne nigdy nie mogą opuszczać Vault.
• Automatycznej rotacji certyfikatów powiązanej z systemem odnawiania dzierżaw Vault.

Wystawcy Self-Signed i CA

Wystawca SelfSigned generuje certyfikaty podpisane własnym kluczem prywatnym certyfikatu — przydatny do bootstrapowania głównego CA w klastrze. Wystawca CA używa Kubernetes Secret zawierającego parę kluczy CA do podpisywania certyfikatów, co czyni go odpowiednim dla wewnętrznych środowisk deweloperskich i PKI siatki usług.

Venafi

Integracja z Venafi jest przeznaczona dla środowisk korporacyjnych z centralnym egzekwowaniem polityki certyfikatów, audytem zgodności i integracją z sprzętowymi modułami bezpieczeństwa (HSM).

Cert-Manager a alternatywne podejścia do automatyzacji TLS

Dla zespołów uruchamiających Kubernetes na Serwerze Dedykowanym lub VPS, Cert-Manager jest jedynym podejściem, które jest jednocześnie natywne dla Kubernetes, obsługuje wszystkie główne CA i nie wymaga żadnej bieżącej ręcznej interwencji.

Instalacja Cert-Manager: konfiguracja gotowa do produkcji

Wymagania wstępne

• Kubernetes 1.22+ (zalecane 1.26+ dla pełnej stabilności CRD)
• kubectl skonfigurowany z uprawnieniami cluster-admin
• Zainstalowany Helm 3.x
• Zarejestrowana domena z dostępem do zarządzania DNS (dla DNS-01) lub publicznie dostępny adres IP ingress (dla HTTP-01)

Jeśli zarządzasz własną domeną, zdecydowanie zalecana jest Rejestracja domeny u dostawcy udostępniającego API — umożliwia to w pełni zautomatyzowane rozwiązywanie wyzwań DNS-01 bez ręcznej interwencji.

Krok 1: Instalacja CRDs i kontrolera Cert-Manager

Zalecana metoda instalacji produkcyjnej używa Helm z CRDs zarządzanymi oddzielnie, aby uniknąć konfliktów podczas aktualizacji Helm:

# 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

Przed kontynuowaniem sprawdź, czy wszystkie trzy podstawowe pody działają:

kubectl get pods --namespace cert-manager

Oczekiwane wyjście:

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

cainjector wstrzykuje dane pakietu CA do konfiguracji webhook. Webhook waliduje i mutuje obiekty CRD Cert-Manager — jeśli nie działa, wszystkie operacje kubectl apply na zasobach Cert-Manager zakończą się niepowodzeniem.

Krok 2: Konfiguracja ClusterIssuer dla Let’s Encrypt

Zawsze zacznij od środowiska testowego Let’s Encrypt, aby uniknąć przekroczenia limitów produkcyjnych (50 certyfikatów na zarejestrowaną domenę tygodniowo):

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

Po pomyślnym wystawieniu certyfikatów testowych utwórz wystawcę produkcyjnego:

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

Zastosuj oba manifesty:

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

Sprawdź gotowość wystawcy:

kubectl describe clusterissuer letsencrypt-prod

Pole Status.Conditions musi pokazywać Ready: True. Jeśli pokazuje False, rejestracja konta ACME nie powiodła się — sprawdź adres e-mail i łączność sieciową z poda cert-manager.

Krok 3: Jawne żądanie certyfikatu

Możesz żądać certyfikatów albo tworząc zasób Certificate bezpośrednio, albo adnotując zasób Ingress. Jawne podejście Certificate daje większą kontrolę:

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

Zastosuj i monitoruj wystawianie:

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

Obserwuj obiekty CertificateRequest i Order w celu uzyskania szczegółowego statusu:

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

Krok 4: Metoda adnotacji Ingress (uproszczona)

Dla zespołów używających NGINX Ingress Controller, Cert-Manager może być wyzwalany automatycznie za pomocą adnotacji — nie jest wymagany oddzielny manifest Certificate:

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 wykrywa adnotację i automatycznie tworzy odpowiedni zasób Certificate. Jest to najczęstszy wzorzec w przepływach pracy GitOps.

Zaawansowane wzorce konfiguracji

Certyfikaty wildcard z DNS-01 (przykład Cloudflare)

Certyfikaty wildcard wymagają walidacji DNS-01. Najpierw utwórz Secret zawierający token API Cloudflare:

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

Skonfiguruj ClusterIssuer z solverem DNS-01:

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

Zażądaj certyfikatu wildcard:

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

Krytyczna pułapka: Secret zawierający poświadczenia dostawcy DNS musi znajdować się w przestrzeni nazw cert-manager gdy jest przywoływany przez ClusterIssuer. Jeśli umieścisz go w innej przestrzeni nazw, kontroler nie będzie mógł go odczytać i wystawianie po cichu zakończy się niepowodzeniem. Sprawdź logi kontrolera cert-manager za pomocą kubectl logs -n cert-manager deploy/cert-manager jeśli wyzwania się zatrzymują.

Wewnętrzne PKI z wystawcą CA

Dla mTLS między usługami w klastrze, wystawca CA oparty na samopodpisanym korzeniu jest bardziej odpowiedni niż 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

Usługi mogą teraz żądać krótkotrwałych certyfikatów od internal-ca-issuer dla mTLS bez żadnej zewnętrznej zależności od CA.

Konfiguracja renewBefore dla środowisk wysokiego bezpieczeństwa

Domyślny renewBefore wynoszący 30 dni jest odpowiedni dla 90-dniowych certyfikatów Let’s Encrypt. Dla krótkotrwałych certyfikatów wewnętrznych (np. 24-godzinna ważność), ustaw renewBefore na ułamek całkowitego czasu trwania:

spec:
  duration: 24h
  renewBefore: 8h

Cert-Manager rozpocznie odnawianie 8 godzin przed wygaśnięciem, dając kontrolerowi trzy okna odnawiania w ciągu 24-godzinnego okresu ważności certyfikatu — krytyczny margines bezpieczeństwa, jeśli klaster doświadcza przejściowej niedostępności serwera API.

Debugowanie typowych błędów Cert-Manager

Certyfikat utknął w stanie „Wystawianie”

# 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

Typowe przyczyny główne:

• Błąd HTTP-01: Kontroler Ingress nie kieruje poprawnie ruchu /.well-known/acme-challenge/. Sprawdź, czy obiekt Ingress wyzwania został utworzony i czy port 80 jest dostępny z internetu. Zapory sieciowe na hoście muszą zezwalać na przychodzący ruch TCP/80.
• Błąd DNS-01: Token API dostawcy DNS ma niewystarczające uprawnienia lub propagacja DNS nie została zakończona. Serwery walidacyjne Let’s Encrypt mogą odpytywać inne resolvery niż lokalny DNS — opóźnienia propagacji wynoszące 60–120 sekund są normalne.
• Przekroczono limit szybkości: Let’s Encrypt egzekwuje 5 nieudanych prób walidacji na domenę na godzinę. Po osiągnięciu tego limitu musisz poczekać przed ponowną próbą. Zawsze najpierw testuj z punktem końcowym testowym.
• Webhook nie jest gotowy: Jeśli pod webhook cert-manager nie działa, wszystkie operacje CRD zakończą się błędem odmowy połączenia. Upewnij się, że usługa webhook ma prawidłowy punkt końcowy.

Weryfikacja wdrożonego certyfikatu

# 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

Lista kontrolna utwardzania produkcyjnego

Wdrożenie Cert-Manager w środowisku produkcyjnym wymaga więcej niż domyślnej instalacji Helm. Zastosuj te środki utwardzające przed uruchomieniem produkcyjnym:

• Limity zasobów: Ustaw requests i limits CPU i pamięci na wszystkich trzech podach Cert-Manager, aby zapobiec rywalizacji o zasoby na współdzielonych węzłach.
• Audyt RBAC: Cert-Manager wymaga szerokich uprawnień RBAC. Przejrzyj zainstalowane obiekty ClusterRole i ogranicz je do minimum niezbędnego dla używanych typów wystawców.
• Oddzielna przestrzeń nazw: Zawsze wdrażaj Cert-Manager we własnej przestrzeni nazw cert-manager, izolowanej od obciążeń aplikacji.
• Monitorowanie: Udostępnij punkt końcowy metryk Prometheus Cert-Manager (--metrics-listen-address) i skonfiguruj alerty dla certmanager_certificate_expiration_timestamp_seconds, aby wykrywać błędy odnawiania przed ich wpływem na usługi.
• Kopia zapasowa stanu CRD: Uwzględnij obiekty Certificate, ClusterIssuer i Issuer w strategii tworzenia kopii zapasowych klastra. Utrata tych manifestów po zdarzeniu odtwarzania po awarii oznacza ręczne odtworzenie wszystkich konfiguracji certyfikatów.
• Walidacja testowa: Nigdy nie wystawiaj pierwszego certyfikatu względem produkcyjnego punktu końcowego ACME. Naruszenia limitów szybkości mogą zablokować domenę na okres do tygodnia.

Jeśli uruchamiasz wiele klastrów Kubernetes — na przykład oddzielając obciążenia testowe i produkcyjne — Panele sterowania VPS mogą uprościć zarządzanie cyklem życia klastra i zapewnić ujednolicony interfejs do provisioningu infrastruktury bazowej, na której działa każdy klaster.

Dla obciążeń wymagających wnioskowania akcelerowanego GPU lub serwowania ML za punktami końcowymi z terminacją TLS, te same wzorce Cert-Manager mają zastosowanie na infrastrukturze GPU Hosting, gdzie zautomatyzowane zarządzanie certyfikatami jest równie krytyczne dla zabezpieczania punktów końcowych API modeli.

Praktyczna macierz decyzyjna: wybór odpowiedniego wystawcy

Kluczowe wnioski

• Instaluj Cert-Manager używając Helm z installCRDs=true i zawsze waliduj względem testowego punktu końcowego ACME przed przełączeniem na produkcję.
• Używaj ClusterIssuer dla klastrów wieloprzestrzeniowych; używaj Issuer o zakresie przestrzeni nazw tylko gdy potrzebujesz izolacji CA na poziomie zespołu.
• DNS-01 jest bezwzględnie wymagany dla certyfikatów wildcard i dla klastrów niedostępnych bezpośrednio z internetu na porcie 80.
• Pole renewBefore nie jest opcjonalne w produkcji — ustaw je na co najmniej jedną trzecią całkowitego duration certyfikatu.
• Gdy wystawianie się zatrzymuje, ścieżka debugowania to zawsze: Certificate → CertificateRequest → Order → Challenge → logi kontrolera.
• Poświadczenia API dostawcy DNS przywoływane przez ClusterIssuer muszą znajdować się w przestrzeni nazw cert-manager, a nie w przestrzeniach nazw aplikacji.
• Monitoruj certmanager_certificate_expiration_timestamp_seconds w Prometheus i skonfiguruj alerty — ciche błędy odnawiania są najbardziej niebezpiecznym trybem awarii.
• Twórz kopie zapasowe manifestów Certificate i ClusterIssuer jako część planu odtwarzania po awarii.

Często zadawane pytania

Jaka jest różnica między Issuer a ClusterIssuer w Cert-Manager?

Issuer ma zakres przestrzeni nazw i może wystawiać certyfikaty tylko w przestrzeni nazw, w której jest zdefiniowany. ClusterIssuer ma zakres całego klastra i może być przywoływany przez zasoby Certificate w dowolnej przestrzeni nazw. Dla większości klastrów produkcyjnych ClusterIssuer jest właściwym wyborem, chyba że potrzebujesz ścisłej izolacji CA na poziomie przestrzeni nazw.

Dlaczego mój certyfikat Cert-Manager utknął w stanie „Wystawianie”?

Sprawdź obiekty Order i Challenge w tej samej przestrzeni nazw używając kubectl describe. Najczęstsze przyczyny to: port 80 zablokowany przez zaporę sieciową (HTTP-01), nieprawidłowe poświadczenia API DNS lub opóźnienie propagacji (DNS-01), przekroczone limity szybkości Let’s Encrypt lub niedziałający pod webhook cert-manager. Zawsze sprawdzaj logi kontrolera za pomocą kubectl logs -n cert-manager deploy/cert-manager.

Czy Cert-Manager może wystawiać certyfikaty wildcard z Let’s Encrypt?

Tak, ale tylko przy użyciu typu wyzwania DNS-01. HTTP-01 nie może walidować domen wildcard. Musisz skonfigurować integrację z dostawcą DNS (Cloudflare, Route53 itp.) w konfiguracji solvera ClusterIssuer i upewnić się, że poświadczenia API mają uprawnienia do tworzenia rekordów TXT w docelowej domenie.

Jak Cert-Manager automatycznie obsługuje odnawianie certyfikatów?

Kontroler Cert-Manager stale porównuje wygaśnięcie każdego obiektu Certificate z bieżącym czasem. Gdy pozostała ważność spada poniżej progu renewBefore (domyślnie: 30 dni), kontroler tworzy nowy CertificateRequest, realizuje wyzwanie ACME i atomowo zastępuje zawartość docelowego Secret — wszystko bez restartowania podów korzystających z certyfikatu. Pody montujące Secret jako wolumin zobaczą zaktualizowany certyfikat przy następnym cyklu synchronizacji kubelet.

Czy Cert-Manager nadaje się do zabezpieczania wewnętrznej komunikacji między usługami, nie tylko publicznego HTTPS?

Tak. Używając wystawcy CA lub wystawcy HashiCorp Vault, Cert-Manager może wystawiać krótkotrwałe certyfikaty dla wewnętrznego mTLS między mikroserwisami. Jest to powszechny wzorzec w wdrożeniach siatki usług, gdzie każde obciążenie potrzebuje unikalnego certyfikatu tożsamości. Pola duration i renewBefore pozwalają na certyfikaty o ważności tak krótkiej jak minuty, z w pełni zautomatyzowaną rotacją.