🥇cert-manager 1.0 wydany

Jeśli zapytasz doświadczonego, mądrego inżyniera, co sądzi o menedżerze certyfikatów i dlaczego wszyscy go używają, specjalista westchnie, przytuli go poufnie i powie ze znużeniem: „Wszyscy tego używają, bo nie ma rozsądnych alternatyw. Nasze myszy płaczą, kłują się, ale nadal żyją z tym kaktusem. Dlaczego kochamy? Ponieważ to działa. Dlaczego nie kochamy? Ponieważ stale pojawiają się nowe wersje, które korzystają z nowych funkcji. I trzeba ciągle aktualizować klaster. A stare wersje przestają działać, bo istnieje spisek i wielki tajemniczy szamanizm.”

Ale twórcy twierdzą, że z menedżer certyfikatów 1.0 wszystko się zmieni.

Uważać?

Cert-manager to natywny kontroler zarządzania certyfikatami Kubernetes. Można go używać do wystawiania certyfikatów z różnych źródeł: Let's Encrypt, HashiCorp Vault, Venafi, par kluczy podpisujących i samopodpisanych. Pozwala także na aktualizację kluczy i próbuje automatycznie odnawiać certyfikaty o określonej godzinie, zanim wygasną. Cert-manager jest oparty na kube-lego i wykorzystuje również pewne techniki z innych podobnych projektów, takie jak kube-cert-manager.

Informacje o wydaniu

W wersji 1.0 położyliśmy znak zaufania w ciągu trzech lat rozwoju projektu cert-manager. W tym czasie znacznie rozwinął się pod względem funkcjonalności i stabilności, ale przede wszystkim w społeczności. Dziś widzimy, jak wiele osób używa go do zabezpieczania swoich klastrów Kubernetes, a także wdraża je w różnych częściach ekosystemu. W ostatnich 16 wersjach naprawiono wiele błędów. A to, co powinno zostać złamane, zostało złamane. Kilka wizyt w API poprawiło jego interakcję z użytkownikami. Rozwiązaliśmy 1500 problemów w GitHubie i otrzymaliśmy jeszcze więcej żądań ściągnięcia od 253 członków społeczności.

Wydając wersję 1.0, oficjalnie deklarujemy, że menedżer certyfikatów jest projektem dojrzałym. Obiecujemy również, że nasze API będzie kompatybilne v1.

Dziękujemy wszystkim, którzy pomogli nam stworzyć menedżera certyfikatów przez te trzy lata! Niech wersja 1.0 będzie pierwszą z wielu wspaniałych rzeczy, które nadejdą.

Wersja 1.0 jest wersją stabilną z kilkoma priorytetowymi obszarami:

v1 OGIEŃ;
Zespół kubectl cert-manager status, aby pomóc w analizie problemów;
Korzystanie z najnowszych stabilnych API Kubernetes;
Ulepszone rejestrowanie;
Ulepszenia ACME.

Przed aktualizacją koniecznie przeczytaj uwagi dotyczące aktualizacji.

API wersja 1

Wersja v0.16 współpracowała z API v1beta1. Dodało to pewne zmiany strukturalne, a także poprawiło dokumentację terenową API. Wersja 1.0 opiera się na tym wszystkim za pomocą interfejsu API v1. To API jest naszym pierwszym stabilnym, jednocześnie daliśmy już gwarancję kompatybilności, ale z API v1 Obiecujemy zachować kompatybilność przez wiele lat.

Wprowadzone zmiany (uwaga: nasze narzędzia do konwersji zrobią wszystko za Ciebie):

Certyfikat:

emailSANs teraz nazywany emailAddresses
uriSANs - uris

Zmiany te zwiększają kompatybilność z innymi sieciami SAN (alternatywne nazwy podmiotu, około. tłumacz), a także z Go API. Usuwamy ten termin z naszego API.

Aktualizuj

Jeśli używasz Kubernetes 1.16+ - konwersja webhooków umożliwi Ci jednoczesną i bezproblemową pracę z wersjami API v1alpha2, v1alpha3, v1beta1 и v1. Dzięki nim możesz korzystać z nowej wersji API bez konieczności zmiany lub ponownego wdrażania starych zasobów. Zdecydowanie zalecamy uaktualnienie manifestów do interfejsu API v1, ponieważ poprzednie wersje wkrótce staną się przestarzałe. Użytkownicy legacy wersje menedżera certyfikatów będą nadal miały dostęp tylko do v1można znaleźć kroki aktualizacji tutaj.

polecenie statusu kubectl cert-manager

Dzięki nowym ulepszeniom w naszym rozszerzeniu kubectl Łatwiejsze stało się badanie problemów związanych z niewydawaniem certyfikatów. kubectl cert-manager status dostarcza teraz znacznie więcej informacji o tym, co dzieje się z certyfikatami, a także pokazuje, na jakim etapie jest wydawany certyfikat.

Po zainstalowaniu rozszerzenia możesz uruchomić kubectl cert-manager status certificate <имя-сертификата>, który wyszuka certyfikat o określonej nazwie i wszelkich skojarzonych z nim zasobach, takich jak Certyfikat, Sekret, Wystawca oraz Zamówienie i Wyzwania w przypadku certyfikatów od ACME.

Przykład debugowania certyfikatu, który nie jest jeszcze gotowy:

$ kubectl cert-manager status certificate acme-certificate

Name: acme-certificate
Namespace: default
Created at: 2020-08-21T16:44:13+02:00
Conditions:
  Ready: False, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
  Issuing: True, Reason: DoesNotExist, Message: Issuing certificate as Secret does not exist
DNS Names:
- example.com
Events:
  Type    Reason     Age   From          Message
  ----    ------     ----  ----          -------
  Normal  Issuing    18m   cert-manager  Issuing certificate as Secret does not exist
  Normal  Generated  18m   cert-manager  Stored new private key in temporary Secret resource "acme-certificate-tr8b2"
  Normal  Requested  18m   cert-manager  Created new CertificateRequest resource "acme-certificate-qp5dm"
Issuer:
  Name: acme-issuer
  Kind: Issuer
  Conditions:
    Ready: True, Reason: ACMEAccountRegistered, Message: The ACME account was registered with the ACME server
error when finding Secret "acme-tls": secrets "acme-tls" not found
Not Before: <none>
Not After: <none>
Renewal Time: <none>
CertificateRequest:
  Name: acme-certificate-qp5dm
  Namespace: default
  Conditions:
    Ready: False, Reason: Pending, Message: Waiting on certificate issuance from order default/acme-certificate-qp5dm-1319513028: "pending"
  Events:
    Type    Reason        Age   From          Message
    ----    ------        ----  ----          -------
    Normal  OrderCreated  18m   cert-manager  Created Order resource default/acme-certificate-qp5dm-1319513028
Order:
  Name: acme-certificate-qp5dm-1319513028
  State: pending, Reason:
  Authorizations:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifier: example.com, Initial State: pending, Wildcard: false
Challenges:
- Name: acme-certificate-qp5dm-1319513028-1825664779, Type: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Key: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, State: pending, Reason: error getting clouddns service account: secret "clouddns-accoun" not found, Processing: true, Presented: false

Zespół może również pomóc Ci dowiedzieć się więcej o treści certyfikatu. Przykładowe szczegóły certyfikatu wystawionego przez Letsencrypt:

$ kubectl cert-manager status certificate example
Name: example
[...]
Secret:
  Name: example
  Issuer Country: US
  Issuer Organisation: Let's Encrypt
  Issuer Common Name: Let's Encrypt Authority X3
  Key Usage: Digital Signature, Key Encipherment
  Extended Key Usages: Server Authentication, Client Authentication
  Public Key Algorithm: RSA
  Signature Algorithm: SHA256-RSA
  Subject Key ID: 65081d98a9870764590829b88c53240571997862
  Authority Key ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Serial Number: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Events:  <none>
Not Before: 2020-06-02T04:29:56+02:00
Not After: 2020-08-31T04:29:56+02:00
Renewal Time: 2020-08-01T04:29:56+02:00
[...]

Wykorzystaj najnowsze stabilne interfejsy API Kubernetes

Menedżer certyfikatów był jednym z pierwszych, którzy wdrożyli CRD Kubernetes. To, w połączeniu z naszą obsługą wersji Kubernetes do 1.11, oznaczało, że musieliśmy obsługiwać starsze apiextensions.k8s.io/v1beta1 również dla naszych CRD admissionregistration.k8s.io/v1beta1 dla naszych webhooków. Są one obecnie przestarzałe i zostaną usunięte w Kubernetes od wersji 1.22. W wersji 1.0 oferujemy teraz pełne wsparcie apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 dla Kubernetes 1.16 (gdzie zostały dodane) i nowszych. Użytkownikom poprzednich wersji nadal oferujemy wsparcie v1beta1 w naszym legacy wersje.

Ulepszone rejestrowanie

W tej wersji zaktualizowaliśmy bibliotekę rejestrowania klog/v2, używany w Kubernetes 1.19. Sprawdzamy także każdy magazyn, który piszemy, aby mieć pewność, że ma przypisany odpowiedni poziom. Kierowaliśmy się tym wskazówki od Kubernetesa. Jest ich pięć (a właściwie sześć, około. tłumacz) poziomy rejestrowania począwszy od Error (poziom 0), który wypisuje tylko istotne błędy i kończy się na Trace (poziom 5), dzięki któremu dowiesz się dokładnie, co się dzieje. Dzięki tej zmianie zmniejszyliśmy liczbę dzienników, jeśli nie potrzebujesz informacji debugowania podczas uruchamiania menedżera certyfikatów.

Wskazówka: domyślnie menedżer certyfikatów działa na poziomie 2 (Info), możesz to zastąpić za pomocą global.logLevel na wykresie Helma.

Uwaga: Przeglądanie dzienników to ostateczność podczas rozwiązywania problemów. Więcej informacji znajdziesz w naszym przywództwo.

Uwaga redaktora: Aby dowiedzieć się więcej o tym, jak to wszystko działa pod maską Kubernetes, uzyskać cenne porady od praktykujących nauczycieli, a także wysokiej jakości wsparcie techniczne, możesz wziąć udział w intensywnych kursach online Baza Kubernetesa, który odbędzie się w dniach 28-30 września, oraz Kubernetes Megaktóry odbędzie się w dniach 14-16 października.

Ulepszenia ACME

Najczęstsze użycie menedżera certyfikatów jest prawdopodobnie związane z wydawaniem certyfikatów z Let's Encrypt przy użyciu ACME. Wersja 1.0 wyróżnia się tym, że wykorzystała opinie społeczności do dodania dwóch małych, ale ważnych ulepszeń do naszego wydawcy ACME.

Wyłącz generowanie klucza konta

Jeśli używasz certyfikatów ACME w dużych ilościach, prawdopodobnie używasz tego samego konta w wielu klastrach, więc ograniczenia wydawania certyfikatów będą miały zastosowanie do nich wszystkich. Było to już możliwe w menedżerze certyfikatów podczas kopiowania klucza tajnego określonego w privateKeySecretRef. Ten przypadek użycia był dość błędny, ponieważ menedżer certyfikatów próbował być pomocny i szczęśliwie utworzył nowy klucz konta, jeśli nie mógł go znaleźć. Dlatego dodaliśmy disableAccountKeyGenerationaby chronić Cię przed takim zachowaniem, ustawiając tę opcję na true - menedżer certyfikatów nie wygeneruje klucza i ostrzeże Cię, że nie otrzymał klucza do konta.

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    privateKeySecretRef:
      name: example-issuer-account-key
    disableAccountKeyGeneration: false

Preferowany łańcuch

29 września Szyfrujmy przejdzie do własnego głównego urzędu certyfikacji ISRG Root. Certyfikaty z podpisem krzyżowym zostaną zastąpione certyfikatami Identrust. Ta zmiana nie wymaga zmian w ustawieniach menedżera certyfikatów; wszystkie zaktualizowane lub nowe certyfikaty wydane po tej dacie będą korzystać z nowego głównego urzędu certyfikacji.

Let's Encrypt podpisuje już certyfikaty z tym urzędem certyfikacji i oferuje je jako „alternatywny łańcuch certyfikatów” za pośrednictwem ACME. Ta wersja menedżera certyfikatów ma możliwość ustawienia dostępu do tych łańcuchów w ustawieniach wystawcy. W parametrze preferredChain Można określić nazwę urzędu certyfikacji użytego do wystawienia certyfikatu. Jeśli dostępny jest certyfikat urzędu certyfikacji odpowiadający żądaniu, zostanie on wydany. Należy pamiętać, że jest to opcja preferowana; jeśli nic nie zostanie znalezione, zostanie wystawiony certyfikat domyślny. Dzięki temu będziesz mieć pewność, że będziesz nadal odnawiać swój certyfikat po usunięciu alternatywnego łańcucha po stronie wystawcy ACME.

Dziś można odebrać podpisane certyfikaty ISRG Root, Więc:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "ISRG Root X1"

Jeśli wolisz opuścić łańcuch IdenTrust — ustaw ten parametr na DST Root CA X3:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    preferredChain: "DST Root CA X3"

Należy pamiętać, że ten główny urząd certyfikacji wkrótce będzie przestarzały. Let's Encrypt utrzyma ten łańcuch aktywny do 29 września 2021 r.

Źródło: www.habr.com

wydano menedżera certyfikatów 1.0