Als je een ervaren, doorgewinterde engineer vraagt wat hij van cert-manager denkt en waarom iedereen het gebruikt, zal de specialist zuchten, je vertrouwelijk omarmen en vermoeid zeggen: "Iedereen gebruikt het, omdat er geen redelijke alternatieven zijn. Onze muizen huilen, steken zichzelf, maar blijven leven met deze cactus. Waarom houden we van het? Omdat het werkt. Waarom houden we er niet van? Omdat er constant nieuwe versies uitkomen die nieuwe functies gebruiken. En we moeten keer op keer het cluster bijwerken. Oudere versies stoppen met werken, omdat er een samenzwering is en er groot mysterieus sjamanisme is."
Maar ontwikkelaars verzekeren ons dat met cert-manager 1.0 alles zal veranderen.
Geloven we dat?
Cert-manager is de 'natuurlijke' controller voor het beheren van certificaten in Kubernetes. Hiermee kunnen certificaten van verschillende bronnen worden uitgegeven: Let's Encrypt, HashiCorp Vault, Venafi, paren sleutels voor ondertekening en zelfondertekende certificaten. Het helpt ook om sleutels actueel te houden en probeert certificaten automatisch bij te werken vóór hun vervaldatum. Cert-manager is gebaseerd op kube-lego en heeft ook enkele technieken uit andere soortgelijke projecten, zoals kube-cert-manager, gebruikt.
Release-opmerkingen
Met versie 1.0 geven we een teken van vertrouwen na drie jaar ontwikkeling van het cert-manager-project. In die tijd is het aanzienlijk ontwikkeld in functionaliteit en stabiliteit, maar vooral in de gemeenschap. Vandaag zien we hoe veel mensen het gebruiken om hun Kubernetes-clusters te beschermen en het integreren in verschillende delen van het ecosysteem. In de laatste 16 releases zijn er talloze fouten opgelost. Wat kapot moest, is kapotgemaakt. Verschillende pogingen om met de API te werken hebben de interactie met gebruikers verbeterd. We hebben 1500 problemen op GitHub opgelost, met nog veel meer pull requests van 253 deelnemers aan de gemeenschap.
Met de release van 1.0 verklaren we officieel dat cert-manager een volwaardig project is. We beloven ook de compatibiliteit van onze API te ondersteunen. v1.
Een enorme dank aan iedereen die ons heeft geholpen cert-manager in deze drie jaar te maken! Moge versie 1.0 de eerste zijn van vele toekomstige grote prestaties.
Release 1.0 is een stabiele release met verschillende prioritaire aandachtsgebieden:
v1API;Opdracht
kubectl cert-manager status, om te helpen bij het analyseren van problemen;Gebruik van de nieuwste stabiele Kubernetes-API's;
Verbeterde logging;
Verbeteringen in ACME.
Lees de update-opmerkingen zorgvuldig voordat je bijwerkt.
API v1
Versie v0.16 werkte met API v1beta1. Dit voegde enkele structurele wijzigingen toe, evenals verbeterde documentatie over de API-velden. Versie 1.0 is volledig afhankelijk van dit alles met behulp van de API v1. Deze API is onze eerste stabiele versie, terwijl we al compatibiliteitsgaranties hebben gegeven, maar met de API v1 beloven we compatibiliteit voor de komende jaren te onderhouden.
De aangebrachte wijzigingen (opmerking: onze conversiemiddelen zorgen voor alles voor je):
Certificaat:
emailSANswordt nuemailAddressesuriSANs—uris
Deze wijzigingen voegen compatibiliteit toe met andere SAN (subject alt names, opmerking van de vertaler), evenals met de Go API. We verwijderen deze term uit onze API.
Bijwerken
Als je Kubernetes 1.16+ gebruikt, zullen de converterende webhooks je in staat stellen om naadloos met de API-versies v1alpha2, v1alpha3, v1beta1 en v1. Hiermee kun je de nieuwe API-versie gebruiken zonder je oude middelen te veranderen of opnieuw te implementeren. We raden sterk aan om de manifesten bij te werken naar de API v1, omdat eerdere versies binnenkort als verouderd zullen worden gemarkeerd. Gebruikers legacy van de cert-manager versie zullen nog steeds alleen toegang hebben tot v1, je kunt de stappen voor de update vinden .
Het team kubectl cert-manager status
Met de nieuwe verbeteringen in onze extensie aan kubectl is het eenvoudiger geworden om problemen met het niet uitgeven van certificaten te onderzoeken. kubectl cert-manager status geeft nu veel meer informatie over wat er met de certificaten gebeurt, en toont ook de uitgifte-status van het certificaat.
Na het installeren van de extensie kun je kubectl cert-manager status certificate, wat zal leiden tot het zoeken naar het certificaat met de gegeven naam en alle gerelateerde middelen, zoals CertificateRequest, Secret, Issuer, evenals Order en Challenges in het geval van het gebruik van certificaten van ACME.
Voorbeeld van het debuggen van een nog niet compleet certificaat:
$ kubectl cert-manager status certificate acme-certificate
Naam: acme-certificate
Namespace: default
Gemaakt op: 2020-08-21T16:44:13+02:00
Voorwaarden:
Gereed: False, Reden: DoesNotExist, Bericht: Het uitgeven van certificaat als Secret bestaat niet
Uitgeven: True, Reden: DoesNotExist, Bericht: Het uitgeven van certificaat als Secret bestaat niet
DNS Namen:
- example.com
Evenementen:
Type Reden Leeftijd Van Bericht
---- ------ ---- ---- -------
Normaal Uitgeven 18m cert-manager Het uitgeven van certificaat als Secret bestaat niet
Normaal Gemaakt 18m cert-manager Nieuwe privésleutel opgeslagen in tijdelijke Secret resource "acme-certificate-tr8b2"
Normaal Aangevraagd 18m cert-manager Nieuwe CertificateRequest resource "acme-certificate-qp5dm" aangemaakt
Uitgever:
Naam: acme-issuer
Soort: Issuer
Voorwaarden:
Gereed: True, Reden: ACMEAccountRegistered, Bericht: Het ACME-account is geregistreerd bij de ACME-server
fout bij het vinden van Secret "acme-tls": secrets "acme-tls" niet gevonden
Niet vóór:
Niet na:
Verlenging Tijd:
CertificateRequest:
Naam: acme-certificate-qp5dm
Namespace: default
Voorwaarden:
Gereed: False, Reden: Pending, Bericht: Wachten op de uitgifte van certificaat van bestelling default/acme-certificate-qp5dm-1319513028: "pending"
Evenementen:
Type Reden Leeftijd Van Bericht
---- ------ ---- ---- -------
Normaal BestellingAangemaakt 18m cert-manager Bestelling resource aangemaakt default/acme-certificate-qp5dm-1319513028
Bestelling:
Naam: acme-certificate-qp5dm-1319513028
Status: pending, Reden:
Autorisaties:
URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifier: example.com, Begin Status: pending, Wildcard: false
Uitdagingen:
- Naam: acme-certificate-qp5dm-1319513028-1825664779, Type: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Sleutel: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Status: pending, Reden: fout bij het verkrijgen van clouddns-service-account: secret "clouddns-accoun" niet gevonden, Verwerking: true, Gepresenteerd: false
De opdracht kan ook helpen om meer te leren over de inhoud van het certificaat. Voorbeelddetails voor een certificaat dat is uitgegeven door Letsencrypt:
$ kubectl cert-manager status certificate example
Naam: example
[...]
Secret:
Naam: example
Uitgever Land: US
Uitgever Organisatie: Let's Encrypt
Uitgever Gemeenschappelijke Naam: Let's Encrypt Authority X3
Sleutelgebruik: Digitale Handtekening, Sleutelversleuteling
Uitgebreide Sleutelgebruik: Serverauthenticatie, Klantauthenticatie
Publieke Sleutel Algoritme: RSA
Handtekening Algoritme: SHA256-RSA
Onderwerp Sleutel ID: 65081d98a9870764590829b88c53240571997862
Autoriteit Sleutel ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
Serienummer: 0462ffaa887ea17797e0057ca81d7ba2a6fb
Evenementen:
Niet vóór: 2020-06-02T04:29:56+02:00
Niet na: 2020-08-31T04:29:56+02:00
Verlenging Tijd: 2020-08-01T04:29:56+02:00
[...]
Het gebruik van de nieuwste stabiele API's van Kubernetes
Cert-manager was een van de eersten die Kubernetes CRDs implementeerde. Dit, evenals onze ondersteuning voor Kubernetes-versies tot en met 1.11, leidde ertoe dat we de verouderde apiextensions.k8s.io/v1beta1 voor onze CRD, evenals admissionregistration.k8s.io/v1beta1 voor onze webhooks. Deze zijn nu verouderd en zullen worden verwijderd in Kubernetes versie 1.22. Met onze 1.0 bieden we nu volledige ondersteuning apiextensions.k8s.io/v1 en admissionregistration.k8s.io/v1 voor Kubernetes 1.16 (waar ze zijn toegevoegd) en nieuwer. Voor gebruikers van oudere versies blijven we ondersteuning bieden v1beta1 in onze legacy versie.
Verbeterde logging
In deze versie hebben we de loggingbibliotheek bijgewerkt naar klog/v2, die wordt gebruikt in Kubernetes 1.19. We controleren ook elke log die we schrijven, om ervoor te zorgen dat deze het juiste niveau krijgt. We hebben ons hierbij laten leiden door . Er zijn vijf (in feite zes, opmerking van de vertaler) logniveaus, beginnend met Fout (niveau 0), dat alleen belangrijke fouten weergeeft, en eindigend met Trace (niveau 5), dat helpt te begrijpen wat er precies gebeurt. Met deze wijziging hebben we het aantal logs verminderd als je geen debug-informatie nodig hebt bij het werken met cert-manager.
Tip: standaard werkt cert-manager op niveau 2 (Info), je kunt dit overschrijven met global.logLevel in de Helm-chart.
Opmerking: logboeken bekijken is een laatste redmiddel bij het oplossen van problemen. Voor meer informatie kun je onze .
N.B. redactie: Om meer te leren over hoe dit allemaal onder de motorkap van Kubernetes werkt, waardevolle tips te krijgen van praktijkdocenten, en kwaliteitsvolle ondersteuning te ontvangen, kan je deelnemen aan de online intensives , die plaatsvinden van 28-30 september, en , die plaatsvindt van 14-16 oktober.
Verbeteringen ACME
De meest voorkomende toepassing van cert-manager is waarschijnlijk het uitgeven van certificaten van Let’s Encrypt via ACME. Versie 1.0 is opmerkelijk door het gebruik van feedback van de gemeenschap om twee kleine, maar belangrijke verbeteringen aan onze ACME issuer toe te voegen.
Uitschakelen van sleutelaccountcreatie
Als je ACME-certificaten in grote hoeveelheden gebruikt, gebruik je waarschijnlijk hetzelfde account op meerdere clusters, zodat je limieten voor certificaatuitgifte voor hen allemaal gelden. Dit was al mogelijk in cert-manager door de geheimen die zijn opgegeven in privateKeySecretRef. Deze gebruikswijze was vrij foutgevoelig, omdat cert-manager probeerde nuttig te zijn en vrolijk een nieuwe accountsleutel aanmaakte als deze niet werd aangetroffen. Daarom hebben we disableAccountKeyGeneration, toegevoegd om je te beschermen tegen dergelijk gedrag: als je deze parameter instelt op true , zal cert-manager geen sleutel creëren en je waarschuwen dat er geen accountsleutel is opgegeven.
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
privateKeySecretRef:
name: example-issuer-account-key
disableAccountKeyGeneration: false
Voorkeursketen
29 september Let’s Encrypt naar een eigen root-certificatiencentrum ISRG Root. Certificaten met cross-signatures worden vervangen door Identrust. Deze wijziging vereist geen aanpassingen in de instellingen van cert-manager. Alle bijgewerkte of nieuwe certificaten die na deze datum worden uitgegeven, zullen gebruikmaken van de nieuwe root CA.
Let’s Encrypt tekent al certificaten met deze CA en biedt ze aan als een "alternatieve certificaatketen" via ACME. In deze versie van cert-manager is het mogelijk om toegang tot deze ketens in de issuer-instellingen te definiëren. In de parameter preferredChain kun je de naam opgeven van de gebruikte CA waarmee het certificaat wordt uitgegeven. Als er een CA-certificaat beschikbaar is dat overeenkomt met de aanvraag, zal het jouw certificaat uitgeven. Houd er rekening mee dat dit de voorkeur geniet, als er niets wordt gevonden, zal er een standaardcertificaat worden uitgegeven. Dit garandeert dat je je certificaat alsnog zult vernieuwen na het verwijderen van de alternatieve keten aan de kant van de ACME issuers.
Het is al mogelijk om certificaten te ontvangen die zijn ondertekend door ISRG Root, zo:
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
preferredChain: "ISRG Root X1"
Als je de keten wilt behouden IdenTrust — stel deze parameter in op 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"
Houd er rekening mee dat deze root-certificatiencentrum binnenkort verouderd zal zijn; Let’s Encrypt zal deze keten actief ondersteunen tot 29 september 2021.
Bron: habr.com
