Jeśli zapytasz doświadczonego, mądrego inżyniera, co sądzi o cert-manager oraz dlaczego wszyscy go używają, to specjalista westchnie, objmie cię zaufaniem i zmęczonym głosem powie: "Wszyscy go używają, ponieważ nie ma sensownych alternatyw. Nasze myszy płaczą, cierpią, ale nadal żyją z tym kaktusem. Dlaczego go lubimy? Bo działa. Dlaczego go nie lubimy? Bo wciąż wychodzą nowe wersje, które korzystają z nowych funkcji. I co chwila trzeba aktualizować klaster. A stare wersje przestają działać, ponieważ jest w tym spisek i wielka nieznana czarologia."
Jednak programiści zapewniają, że z cert-manager 1.0 wszystko się zmieni.
Uwierzmy?
Cert-manager to "rodzinny" kontroler zarządzania certyfikatami Kubernetes. Dzięki niemu można wydawać certyfikaty z różnych źródeł: Let’s Encrypt, HashiCorp Vault, Venafi, par kluczy do podpisu i samopodpisanych. Umożliwia również utrzymywanie kluczy aktualnymi w czasie ich ważności, a także stara się automatycznie odnawiać certyfikaty w ustalonym czasie przed ich wygaśnięciem. Cert-manager oparty jest na kube-lego i wykorzystywał również niektóre techniki z innych podobnych projektów, takich jak kube-cert-manager.
Uwagi do wydania
Wersją 1.0 stawiamy znak zaufania za trzy lata rozwoju projektu cert-manager. W tym czasie znacznie rozwinął się pod względem funkcjonalności i stabilności, ale co najważniejsze — w społeczności. Dziś widzimy, jak wiele osób używa go do zabezpieczania swoich klastrów Kubernetes oraz wdraża go w różnych częściach ekosystemu. W ostatnich 16 wydaniach naprawiono mnóstwo błędów. A to, co trzeba było zepsuć — zostało zepsute. Kilka podejść do pracy z API poprawiło jego interakcję z użytkownikami. Rozwiązaliśmy 1500 problemów na GitHubie, z jeszcze większą liczbą próśb o połączenie od 253 członków społeczności.
Wydając 1.0, oficjalnie ogłaszamy, że cert-manager to dojrzały projekt. Obiecujemy również wspierać kompatybilność naszego API. v1.
Ogromne podziękowania dla wszystkich, którzy pomagali nam rozwijać cert-manager przez te trzy lata! Niech wersja 1.0 stanie się pierwszym z wielu przyszłych wielkich osiągnięć.
Wydanie 1.0 to stabilne wydanie z kilkoma priorytetowymi kierunkami:
v1API;Zespół
kubectl cert-manager status, aby pomóc w analizie problemów;Zastosowanie najnowszych stabilnych API Kubernetes;
Ulepszone logowanie;
Ulepszenia ACME.
Przed aktualizacją koniecznie zapoznaj się z uwagami do aktualizacji.
API v1
Wersja v0.16 działała z API v1beta1. Wprowadziło to pewne zmiany strukturalne oraz poprawiło dokumentację dotyczącą pól API. Wersja 1.0 opiera się na wszystkim tym za pomocą API v1. To API jest naszą pierwszą stabilną wersją, a jednocześnie obiecaliśmy zapewnić kompatybilność, ale z API v1 obiecujemy utrzymać kompatybilność na lata.
Wprowadzone zmiany (uwaga: nasze narzędzia do konwersji zajmą się wszystkim za Ciebie):
Certyfikat:
emailSANsnazywane terazemailAddressesuriSANs—uris
Te zmiany dodają kompatybilność z innymi SAN (subject alt names, przyp. tłumacza), a także z Go API. Usuwamy ten termin z naszego API.
Aktualizacja
Jeśli używasz Kubernetes 1.16+ — konwertujące webhooks pozwolą Ci płynnie pracować z wersjami API v1alpha2, v1alpha3, v1beta1 i v1. Dzięki nim będziesz mógł używać nowej wersji API bez zmiany lub ponownego wdrażania swoich starych zasobów. Gorąco zalecamy zaktualizowanie manifestów do API v1, ponieważ poprzednie wersje wkrótce zostaną uznane za przestarzałe. Użytkownicy legacy wersji cert-manager będą nadal mieli dostęp tylko do v1, kroki aktualizacji można znaleźć .
Zespół kubectl cert-manager status
Dzięki nowym ulepszeniom w naszym rozszerzeniu, kubectl łatwiej jest zbadać problemy związane z wydawaniem certyfikatów. kubectl cert-manager status teraz dostarcza znacznie więcej informacji na temat tego, co dzieje się z certyfikatami, a także pokazuje etapy wydawania certyfikatu.
Po zainstalowaniu rozszerzenia możesz uruchomić kubectl cert-manager status certificate, co doprowadzi do wyszukiwania certyfikatu o wskazanej nazwie i wszelkich powiązanych zasobów, takich jak CertificateRequest, Secret, Issuer oraz Order i Challenges w przypadku korzystania z certyfikatów od ACME.
Przykład debugowania jeszcze niegotowego certyfikatu:
$ kubectl cert-manager status certificate acme-certificate
Nazwa: acme-certificate
Namespace: default
Utworzono: 2020-08-21T16:44:13+02:00
Warunki:
Gotowe: False, Powód: DoesNotExist, Wiadomość: Wydawanie certyfikatu jako Secret nie istnieje
Wydawanie: True, Powód: DoesNotExist, Wiadomość: Wydawanie certyfikatu jako Secret nie istnieje
Nazwy DNS:
- example.com
Zdarzenia:
Typ Powód Wiek Typ Wiadomość
---- ------ ---- ---- -------
Normalne Wydawanie 18m cert-manager Wydawanie certyfikatu jako Secret nie istnieje
Normalne Wygenerowane 18m cert-manager Zapisano nowy klucz prywatny w tymczasowym zasobie Secret "acme-certificate-tr8b2"
Normalne Żądane 18m cert-manager Utworzono nowy zasób CertificateRequest "acme-certificate-qp5dm"
Wydawca:
Nazwa: acme-issuer
Rodzaj: Issuer
Warunki:
Gotowe: True, Powód: ACMEAccountRegistered, Wiadomość: Konto ACME zostało zarejestrowane w serwerze ACME
błąd podczas znajdowania Secret "acme-tls": zasoby "acme-tls" nie znalezione
Nie wcześniej:
Nie później:
Czas odnowienia:
CertificateRequest:
Nazwa: acme-certificate-qp5dm
Namespace: default
Warunki:
Gotowe: False, Powód: Pending, Wiadomość: Oczekiwanie na wydanie certyfikatu z zamówienia default/acme-certificate-qp5dm-1319513028: "pending"
Zdarzenia:
Typ Powód Wiek Typ Wiadomość
---- ------ ---- ---- -------
Normalne OrderCreated 18m cert-manager Utworzono zasób Order default/acme-certificate-qp5dm-1319513028
Zamówienie:
Nazwa: acme-certificate-qp5dm-1319513028
Stan: pending, Powód:
Autoryzacje:
URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identyfikator: example.com, Stan początkowy: pending, Wildcard: false
Wyzwania:
- Nazwa: acme-certificate-qp5dm-1319513028-1825664779, Typ: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Klucz: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Stan: pending, Powód: błąd podczas uzyskiwania konta usługi clouddns: secret "clouddns-accoun" nie znalezione, Procesowanie: true, Prezentowane: false
Polecenie może również pomóc w uzyskaniu szczegółowych informacji o zawartości certyfikatu. Przykład szczegółów dla certyfikatu wystawionego przez Letsencrypt:
$ kubectl cert-manager status certificate example
Nazwa: example
[...]
Secret:
Nazwa: example
Kraj Wydawcy: US
Organizacja Wydawcy: Let's Encrypt
Nazwa powszechna Wydawcy: Let's Encrypt Authority X3
Użycie klucza: Podpis cyfrowy, Szyfrowanie klucza
Rozszerzone użycia klucza: Uwierzytelnianie serwera, Uwierzytelnianie klienta
Algorytm klucza publicznego: RSA
Algorytm podpisu: SHA256-RSA
ID klucza podmiotu: 65081d98a9870764590829b88c53240571997862
ID klucza autorytetu: a84a6a63047dddbae6d139b7a64565eff3a8eca1
Numer seryjny: 0462ffaa887ea17797e0057ca81d7ba2a6fb
Zdarzenia:
Nie wcześniej: 2020-06-02T04:29:56+02:00
Nie później: 2020-08-31T04:29:56+02:00
Czas odnowienia: 2020-08-01T04:29:56+02:00
[...]
Używanie najnowszych stabilnych API Kubernetes
Cert-manager był jednym z pierwszych projektów, które wdrożyły CRD w Kubernetes. To, wraz z naszą obsługą wersji Kubernetes aż do 1.11, spowodowało potrzeby wsparcia wersji przestarzałych apiextensions.k8s.io/v1beta1 dla naszych CRD, jak również admissionregistration.k8s.io/v1beta1 dla naszych webhooków. Obecnie są one przestarzałe i będą usunięte w Kubernetes od wersji 1.22. W naszej wersji 1.0 oferujemy teraz pełne wsparcie apiextensions.k8s.io/v1 i admissionregistration.k8s.io/v1 dla Kubernetes 1.16 (gdzie zostały dodane) i nowszych. Dla użytkowników wcześniejszych wersji nadal oferujemy wsparcie v1beta1 w naszej legacy wersji.
Ulepszone logowanie
W tej wersji zaktualizowaliśmy bibliotekę logującą do klog/v2, używanej w Kubernetes 1.19. Sprawdzamy również każdy dziennik, który piszemy, aby przypisać mu odpowiedni poziom. Kierowaliśmy się przy tym . Istnieje pięć (w rzeczywistości — sześć, przyp. tłumacza) poziomów logowania, począwszy od Error (poziom 0), który wyświetla tylko ważne błędy, a kończąc na Trace (poziom 5), który pomoże dokładnie zrozumieć, co się dzieje. Tą zmianą ograniczyliśmy liczbę dzienników, jeśli nie są Państwu potrzebne informacje dotyczące debugowania podczas pracy cert-manager.
Rada: domyślnie cert-manager działa na poziomie 2 (Info), można to nadpisać, używając global.logLevel w wykresie Helm.
Uwaga: przeglądanie dzienników to ostateczność przy rozwiązywaniu problemów. Aby uzyskać dodatkowe informacje, zapoznaj się z naszym .
N.B. redaktora: Aby dowiedzieć się więcej o tym, jak to wszystko działa pod maską w Kubernetes, uzyskać cenne wskazówki od praktyków-nauczycieli oraz wysokiej jakości pomoc techniczną, można wziąć udział w intensywnym kursie internetowym , który odbędzie się od 28 do 30 września, oraz , który odbędzie się od 14 do 16 października.
Ulepszenia ACME
Najczęstsze zastosowanie cert-manager związane jest z wydawaniem certyfikatów od Let’s Encrypt z wykorzystaniem ACME. Wersja 1.0 wyróżnia się wykorzystaniem opinii społeczności do dodania dwóch małych, ale istotnych ulepszeń w naszym dostawcy ACME.
Wyłączenie tworzenia klucza konta
Jeśli używasz certyfikatów ACME w dużych ilościach, prawdopodobnie korzystasz z tego samego konta na wielu klastrach, więc twoje limity wydawania certyfikatów będą się do nich odnosić. To już było możliwe w cert-manager przy kopiowaniu sekretu, wskazanego w privateKeySecretRef. Taki sposób użycia był dość uciążliwy, ponieważ cert-manager starał się być pomocny i chętnie tworzył nowy klucz konta, gdy go nie znajdował. Dlatego dodaliśmy disableAccountKeyGeneration, aby chronić Cię przed tym zachowaniem — po ustawieniu tego parametru na true — cert-manager nie utworzy klucza i ostrzeże Cię, że klucz konta nie został podany.
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 Let’s Encrypt na własny korzeń centrum certyfikacji ISRG Root. Certyfikaty z podpisami krzyżowymi zostaną zastąpione przez Identrust. Ta zmiana nie wymaga poprawek w ustawieniach cert-manager, wszystkie zaktualizowane lub nowe certyfikaty wydawane po tej dacie będą korzystać z nowego głównego CA.
Let’s Encrypt już podpisuje certyfikaty za pomocą tego CA i oferuje je jako „alternatywny łańcuch certyfikatów” poprzez ACME. W tej wersji cert-manager istnieje możliwość określenia dostępu do tych łańcuchów w ustawieniach wystawcy. W parametrze preferredChain można podać nazwę używanego CA, za pomocą którego zostanie wydany certyfikat. Jeśli certyfikat CA odpowiadający zapytaniu będzie dostępny, zostanie wydany certyfikat. Należy zauważyć, że to preferowany wybór, jeśli nic nie zostanie znalezione – zostanie wydany certyfikat domyślny. To zapewni, że i tak przeprowadzisz aktualizację swojego certyfikatu po usunięciu alternatywnego łańcucha po stronie ACME wystawcy.
Już dziś można uzyskiwać certyfikaty podpisane ISRG Root, tak:
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 pozostawić ł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"
Zauważ, że ten korzeń centrum certyfikacji wkrótce stanie się przestarzały, Let’s Encrypt będzie utrzymywać ten łańcuch aktywny do 29 września 2021 roku.
Źródło: habr.com
