🥇Certificaatmanager 1.0 is uit

Als je een ervaren, wijze ingenieur vraagt wat hij van cert-manager vindt en waarom iedereen het gebruikt, dan zal de specialist zuchten, hem in vertrouwen omhelzen en vermoeid zeggen: “Iedereen gebruikt het, want er zijn geen verstandige alternatieven. Onze muizen huilen, prikken, maar leven verder met deze cactus. Waarom houden we van? Omdat het werkt. Waarom houden we niet van? Omdat er voortdurend nieuwe versies uitkomen die nieuwe functies gebruiken. En je moet het cluster steeds opnieuw updaten. En de oude versies werken niet meer, omdat er een samenzwering is en een groot mysterieus sjamanisme.

Maar dat beweren de ontwikkelaars cert-manager 1.0 alles zal veranderen.

Zullen we geloven?

Cert-manager is de systeemeigen Kubernetes-controller voor certificaatbeheer. Het kan worden gebruikt om certificaten uit verschillende bronnen uit te geven: Let's Encrypt, HashiCorp Vault, Venafi, ondertekening en zelfondertekende sleutelparen. Het stelt u ook in staat om sleutels up-to-date te houden op vervaldatum en probeert ook automatisch certificaten te verlengen op een bepaald tijdstip voordat ze verlopen. Cert-manager is gebaseerd op kube-lego en heeft ook enkele trucs gebruikt van andere soortgelijke projecten zoals kube-cert-manager.

Release-opmerkingen

Met versie 1.0 zetten we een teken van vertrouwen voor drie jaar ontwikkeling van het cert-manager project. Gedurende deze tijd is het aanzienlijk geëvolueerd in functionaliteit en stabiliteit, maar vooral in de gemeenschap. Tegenwoordig zien we dat veel mensen het gebruiken om hun Kubernetes-clusters te beveiligen en het ook in verschillende delen van het ecosysteem implementeren. In de laatste 16 releases zijn veel bugs opgelost. En wat gebroken moest worden, is gebroken. Verschillende bezoeken om met de API te werken hebben de interactie met gebruikers verbeterd. We hebben 1500 problemen op GitHub opgelost met meer pull-verzoeken van 253 communityleden.

Met de release van 1.0 verklaren we officieel dat cert-manager een volwassen project is. We beloven ook om onze API compatibel te houden v1.

Veel dank aan iedereen die ons al die drie jaar heeft geholpen om cert-manager te worden! Laat versie 1.0 de eerste zijn van vele grote dingen die komen gaan.

Release 1.0 is een stabiele release met verschillende prioriteitsgebieden:

v1 VUUR;
Team kubectl cert-manager status, om te helpen bij probleemanalyse;
Gebruik van de nieuwste stabiele Kubernetes API's;
Verbeterde logboekregistratie;
ACME-verbeteringen.

Zorg ervoor dat u de upgrade-opmerkingen leest voordat u een upgrade uitvoert.

API v1

Versie v0.16 werkte met de API v1beta1. Dit voegde enkele structurele wijzigingen toe en verbeterde ook de API-velddocumentatie. Versie 1.0 bouwt hierop voort met een API v1. Deze API is onze eerste stabiele, tegelijkertijd hebben we al compatibiliteitsgaranties gegeven, maar dan met de API v1 we beloven de compatibiliteit voor de komende jaren te behouden.

Aangebrachte wijzigingen (let op: onze conversietools regelen alles voor u):

Certificaat:

emailSANs nu gebeld emailAddresses
uriSANs - uris

Deze wijzigingen zorgen voor compatibiliteit met andere SAN's (onderwerp alt-namen, ca. vertaler), evenals met de Go API. We verwijderen deze term uit onze API.

Bijwerken

Als u Kubernetes 1.16+ gebruikt, kunt u door webhooks te converteren gelijktijdig en naadloos met API-versies werken v1alpha2, v1alpha3, v1beta1 и v1. Hiermee kunt u de nieuwe versie van de API gebruiken zonder uw oude resources te wijzigen of opnieuw in te zetten. We raden ten zeerste aan om uw manifesten te upgraden naar de API v1, omdat eerdere versies binnenkort worden beëindigd. Gebruikers legacy versies van cert-manager hebben nog steeds alleen toegang tot v1, upgradestappen zijn te vinden hier.

kubectl cert-manager statusopdracht

Met nieuwe verbeteringen in onze extensie to kubectl het werd gemakkelijker om de problemen in verband met de niet-uitgifte van certificaten te onderzoeken. kubectl cert-manager status geeft nu veel meer informatie over wat er met de certificaten aan de hand is en toont ook de fase van certificaatuitgifte.

Nadat u de extensie hebt geïnstalleerd, kunt u uitvoeren kubectl cert-manager status certificate <имя-сертификата>, die het certificaat met de opgegeven naam en alle gerelateerde bronnen zoals CertificateRequest, Secret, Issuer en Order and Challenges zal opzoeken als certificaten van ACME worden gebruikt.

Een voorbeeld van het debuggen van een certificaat dat nog niet gereed is:

$ 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

De opdracht kan u ook helpen meer te weten te komen over de inhoud van het certificaat. Gedetailleerd voorbeeld voor een certificaat uitgegeven door 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
[...]

Gebruik van de nieuwste stabiele Kubernetes API's

Cert-manager was een van de eersten die Kubernetes CRD's implementeerde. Dit, en onze ondersteuning voor Kubernetes-versies tot 1.11, betekende dat we de legacy moesten ondersteunen apiextensions.k8s.io/v1beta1 ook voor onze CRD's admissionregistration.k8s.io/v1beta1 voor onze webhooks. Ze zijn nu verouderd en worden verwijderd in Kubernetes vanaf versie 1.22. Met onze 1.0 bieden we nu volledige ondersteuning apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 voor Kubernetes 1.16 (waar ze zijn toegevoegd) en nieuwer. Voor gebruikers van eerdere versies blijven we ondersteuning bieden v1beta1 in onze legacy versies.

Verbeterde logboekregistratie

In deze release hebben we de logboekbibliotheek bijgewerkt naar klog/v2, gebruikt in Kubernetes 1.19. We beoordelen ook elk tijdschrift dat we schrijven om er zeker van te zijn dat het het juiste niveau krijgt toegewezen. We hebben ons hierdoor laten leiden begeleiding vanuit Kubernetes. Er zijn vijf (eigenlijk zes, ca. vertaler) logboekregistratieniveaus vanaf Error (niveau 0), die alleen belangrijke fouten afdrukt en eindigt met Trace (niveau 5) waardoor u precies weet wat er aan de hand is. Met deze wijziging hebben we het aantal logboeken verminderd als u geen foutopsporingsinformatie nodig hebt bij het uitvoeren van cert-manager.

Tip: cert-manager draait standaard op niveau 2 (Info), kunt u dit overschrijven met behulp van global.logLevel in Helmchart.

Opmerking: het bekijken van de logboeken is het laatste redmiddel bij het oplossen van problemen. Kijk voor meer informatie op onze leiderschap.

Redacteur n.b.: Om meer te weten te komen over hoe het allemaal werkt onder de motorkap van Kubernetes, om waardevol advies te krijgen van praktiserende docenten en om hoogwaardige technische ondersteuning te krijgen, kun je deelnemen aan online intensives Kubernetes-basis, die van 28-30 september wordt gehouden, en Kubernetes megadie zal worden gehouden van 14-16 oktober.

ACME-verbeteringen

Het meest voorkomende gebruik van cert-manager is waarschijnlijk gerelateerd aan het uitgeven van certificaten van Let's Encrypt met behulp van ACME. Versie 1.0 is opmerkelijk vanwege het gebruik van feedback van de gemeenschap om twee kleine maar belangrijke verbeteringen aan onze ACME-uitgever toe te voegen.

Schakel het genereren van accountsleutels uit

Als u ACME-certificaten in grote hoeveelheden gebruikt, gebruikt u waarschijnlijk hetzelfde account op meerdere clusters, dus uw beperkingen voor de uitgifte van certificaten zijn van toepassing op alle clusters. Dit was al mogelijk in cert-manager bij het kopiëren van het opgegeven geheim in privateKeySecretRef. Deze use case was behoorlijk buggy, omdat cert-manager behulpzaam probeerde te zijn en graag een nieuwe accountsleutel aanmaakte als hij er geen vond. Daarom hebben we toegevoegd disableAccountKeyGenerationom u tegen dit gedrag te beschermen als u deze optie instelt op true - cert-manager zal geen sleutel genereren en zal u waarschuwen dat het geen accountsleutel heeft gekregen.

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

Voorkeursketen

29 september Laten we versleutelen zal passeren naar uw eigen root-CA ISRG Root. Cross-signed certificaten worden vervangen door Identrust. Voor deze wijziging zijn geen wijzigingen in de cert-manager-instellingen vereist, alle bijgewerkte of nieuwe certificaten die na deze datum worden uitgegeven, zullen de nieuwe basis-CA gebruiken.

Let's Encrypt ondertekent al certificaten met deze CA en biedt deze aan als een "alternatieve certificaatketen" via ACME. In deze versie van cert-manager is het mogelijk om toegang tot deze ketens in te stellen in de instellingen van de uitgever. In parameters preferredChain u kunt de naam opgeven van de gebruikte CA waarmee het certificaat wordt uitgegeven. Als er een CA-certificaat beschikbaar is dat overeenkomt met het verzoek, wordt u een certificaat verstrekt. Houd er rekening mee dat dit de voorkeursoptie is, als er niets wordt gevonden, wordt een standaardcertificaat uitgegeven. Dit zorgt ervoor dat u uw certificaat nog steeds verlengt nadat u de alternatieve keten aan de kant van de ACME-uitgever hebt verwijderd.

U kunt vandaag al certificaten ontvangen die zijn ondertekend door ISRG Root, Dus:

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 u liever de ketting verlaat IdenTrust - zet deze optie 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-CA binnenkort wordt afgeschaft, Let's Encrypt houdt deze keten actief tot 29 september 2021.

Bron: www.habr.com

cert-manager 1.0 uitgebracht