🥇 cert-manager 1.0 är här

Om du frågar en erfaren och klipsk ingenjör vad han tycker om cert-manager och varför alla använder det, kommer han att sucka, ge dig en förtroendefull klapp på axeln och trögt säga: "Alla använder det eftersom det inte finns några rimliga alternativ. Våra möss gråter, de står ut med detta kaktus, men fortsätter att leva med det. Varför älskar vi det? För att det fungerar. Varför gillar vi det inte? För att det ständigt kommer nya versioner som introducerar nya funktioner. Och vi tvingas gång på gång uppdatera klustret. De gamla versionerna slutar fungera, för det finns en konspiration och stort mystiskt schamaneri."

Men utvecklarna försäkrar att med cert-manager 1.0 kommer allt att förändras.

Ska vi tro på det?

Cert-manager är den "inbyggda" kontrolleraren för hantering av certifikat i Kubernetes. Det används för att utfärda certifikat från olika källor: Let’s Encrypt, HashiCorp Vault, Venafi, signeringsnyckelpärlor och självsignerade certifikat. Det håller också nycklarna aktuella i förhållande till giltighetstid och försöker automatiskt uppdatera certifikaten när de närmar sig utgångsdatumet. Cert-manager bygger på kube-lego och har även använt vissa tekniker från andra liknande projekt, såsom kube-cert-manager.

Uppdateringsanteckningar

Med version 1.0 sätter vi ett betyg på tre års utveckling av cert-manager-projektet. Under denna tid har det utvecklats avsevärt både när det gäller funktionalitet och stabilitet, men mest av allt - inom gemenskapen. Idag ser vi hur många människor använder det för att skydda sina Kubernetes-kluster samt integrerar det i olika delar av ekosystemet. I de senaste 16 släppen har en mängd buggfixar genomförts. Det som behövde brytas har brutits. Flera förbättringar av API:et har stärkt dess interaktion med användarna. Vi har löst 1500 problem på GitHub med ännu fler pull-requests från 253 medlemmar i gemenskapen.

Med lanseringen av 1.0 meddelar vi officiellt att cert-manager är ett moget projekt. Vi lovar också att stödja kompatibilitet för vårt API. v1.

Stort tack till alla som har hjälpt oss göra cert-manager under dessa tre år! Må version 1.0 bli första av många kommande stora prestationer.

Släppningen av 1.0 är en stabil release med flera prioriterade fokuspunkter:

v1 API;
Team kubectl cert-manager status, för att hjälpa till med problemanalys;
Användning av de senaste stabila API:erna i Kubernetes;
Förbättrad loggning;
Förbättringar av ACME.

Innan du uppdaterar, se till att läsa uppdateringsanteckningarna.

API v1

Version v0.16 fungerade med API v1beta1. Det här medförde vissa strukturella förändringar samt förbättrade dokumentationen för API-fälten. Version 1.0 bygger helt på detta via API v1. Detta API är vår första stabila version, samtidigt som vi redan har utfärdat garantier för kompatibilitet, men med API v1 lovar vi att upprätthålla kompatibilitet i många år framöver.

De ändringar som gjorts (notera: våra omvandlingsverktyg kommer att ta hand om allt åt dig):

Certifikat:

emailSANs heter nu emailAddresses
uriSANs — uris

Dessa ändringar ger kompatibilitet med andra SAN (subject alt names, översättarens anm.), samt med Go API. Vi tar bort denna term från vårt API.

Uppdatering

Om du använder Kubernetes 1.16+ - kommer de konverterande webbhaken att låta dig arbeta med både v1alpha2, v1alpha3, v1beta1 och v1. Med dem kan du använda den nya API-versionen utan att behöva ändra eller distribuera om dina gamla resurser. Vi rekommenderar starkt att du uppdaterar manifest till API v1, eftersom tidigare versioner snart kommer att avskrivas. Användare legacy av cert-manager-versionen kommer fortfarande ha tillgång till v1, uppdateringsstegen kan hittas här.

Teamet kubectl cert-manager status

Med de nya förbättringarna i vårt tillägg till kubectl har det blivit enklare att utforska problem relaterade till att inte utfärda certifikat. kubectl cert-manager status ger nu mycket mer information om vad som händer med certifikaten, samt visar steget för certifikatutfärdande.

Efter installation av tillägget kan du köra kubectl cert-manager status certificate, vilket kommer att söka efter certifikatet med det angivna namnet och eventuella relaterade resurser, som CertificateRequest, Secret, Issuer, samt Order och Challenges vid användning av certifikat från ACME.

Exempel på felsökning av ett certifikat som inte är klart:

$ kubectl cert-manager status certificate acme-certificate

Namn: acme-certificate
Namespace: default
Skapad: 2020-08-21T16:44:13+02:00
Villkor:
  Klar: False, Orsak: DoesNotExist, Meddelande: Utfärdar certifikat eftersom hemligheten inte finns
  Utfärdar: True, Orsak: DoesNotExist, Meddelande: Utfärdar certifikat eftersom hemligheten inte finns
DNS-namn:
- example.com
Händelser:
  Typ    Orsak     Ålder   Från          Meddelande
  ----    ------     ----  ----          -------
  Normal  Utfärdar    18m   cert-manager  Utfärdar certifikat eftersom hemligheten inte finns
  Normal  Genererad  18m   cert-manager  Sparade ny privat nyckel i temporär hemlighet "acme-certificate-tr8b2"
  Normal  Begärd  18m   cert-manager  Skapade ny CertificateRequest-resurs "acme-certificate-qp5dm"
Utfärdare:
  Namn: acme-issuer
  Typ: Utfärdare
  Villkor:
    Klar: True, Orsak: ACMEAccountRegistered, Meddelande: ACME-kontot registrerades hos ACME-servern
fel vid sökande efter hemlighet "acme-tls": hemligheter "acme-tls" hittades inte
Gäller inte före: 
Gäller inte efter: 
Förnyelsetid: 
CertificateRequest:
  Namn: acme-certificate-qp5dm
  Namespace: default
  Villkor:
    Klar: False, Orsak: Pending, Meddelande: Väntar på certifikatutfärdande från beställning default/acme-certificate-qp5dm-1319513028: "pending"
  Händelser:
    Typ    Orsak        Ålder   Från          Meddelande
    ----    ------        ----  ----          -------
    Normal  BeställningSkapad  18m   cert-manager  Skapade beställningsresurs default/acme-certificate-qp5dm-1319513028
Beställning:
  Namn: acme-certificate-qp5dm-1319513028
  Tillstånd: pending, Orsak:
  Auktoriseringar:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifierare: example.com, Inledande tillstånd: pending, Wildcard: false
Utmaningar:
- Namn: acme-certificate-qp5dm-1319513028-1825664779, Typ: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Nyckel: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Tillstånd: pending, Orsak: fel vid hämtning av clouddns-tjänstekontot: hemlighet "clouddns-accoun" hittades inte, Bearbetning: true, Presentation: false

Kommandot kan också hjälpa till att ta reda på mer om certifikatets innehåll. Exempel på detaljer för ett certifikat utfärdat av Letsencrypt:

$ kubectl cert-manager status certificate example
Namn: example
[...]
Hemlighet:
  Namn: example
  Utfärdare Land: US
  Utfärdare Organisation: Let's Encrypt
  Utfärdare Allmänt namn: Let's Encrypt Authority X3
  Nyckelanvändning: Digital Signatur, Nyckel Kryptering
  Utökade Nyckelanvändningar: Serverautentisering, Klientautentisering
  Offentlig Nyckel Algoritm: RSA
  Signatur Algoritm: SHA256-RSA
  Ämnesnyckel-ID: 65081d98a9870764590829b88c53240571997862
  Myndighetsnyckel-ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Serienummer: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Händelser:  
Gäller inte före: 2020-06-02T04:29:56+02:00
Gäller inte efter: 2020-08-31T04:29:56+02:00
Förnyelsetid: 2020-08-01T04:29:56+02:00
[...]

Användningen av de senaste stabila API:erna för Kubernetes

Cert-manager var en av de första som implementerade Kubernetes CRDs. Detta, tillsammans med vårt stöd för versioner av Kubernetes ända upp till 1.11, har lett till att vi behövde stödja föråldrad apiextensions.k8s.io/v1beta1 för våra CRD, samt admissionregistration.k8s.io/v1beta1 för våra webhooks. Nu har de föråldrats och kommer att tas bort i Kubernetes från version 1.22. Med vår 1.0 erbjuder vi nu fullständigt stöd apiextensions.k8s.io/v1 och admissionregistration.k8s.io/v1 för Kubernetes 1.16 (där de lades till) och nyare. För användare av tidigare versioner fortsätter vi att erbjuda stöd v1beta1 i vår legacy version.

Förbättrad loggning

I denna version har vi uppdaterat biblioteken för loggning till klog/v2, som används i Kubernetes 1.19. Vi kontrollerar också varje logg vi skriver för att tilldela rätt nivå. Vi har utgått ifrån guiden från Kubernetes. Det finns fem (faktiskt — sex, översättarens anm.) loggnivåer, som börjar med Error (nivå 0), som bara visar viktiga fel, och slutar med Trace (nivå 5), som hjälper dig att ta reda på exakt vad som händer. Med denna ändring har vi minskat antalet loggar när du inte behöver felsökningsinformation vid användning av cert-manager.

Tips: som standard kör cert-manager på nivå 2 (Info), du kan åsidosätta detta genom att använda global.logLevel i Helm-diagrammet.

Obs: att titta på loggar är sista utvägen vid felsökning. För mer information, se vår guiden.

N.B. redaktör: För att få mer information om hur allt detta fungerar under huven på Kubernetes, få värdefulla tips från praktiker och lärarna, samt kvalificerad hjälp från supporten, kan du delta i online-intensiven Kubernetes Grund, som äger rum den 28–30 september, och Kubernetes Mega, som äger rum den 14–16 oktober.

Förbättringar av ACME

Den vanligaste användningen av cert-manager är för att utfärda certifikat från Let’s Encrypt med hjälp av ACME. Version 1.0 är anmärkningsvärd för att den inkluderar feedback från gemenskapen för att lägga till två små, men viktiga förbättringar i vår ACME-utgivare.

Inaktivering av skapande av kontonyckel

Om du använder ACME-certifikat i stor skala använder du förmodligen samma konto på flera kluster, så dina begränsningar för utfärdande av certifikat gäller för alla. Detta har tidigare varit möjligt i cert-manager genom att kopiera hemligheten som anges i privateKeySecretRef. Denna användning har varit ganska buggig eftersom cert-manager försökte vara användbar och glatt skapade en ny kontonyckel om den inte kunde hitta en. Därför har vi lagt till disableAccountKeyGeneration, för att skydda dig från detta beteende; om denna parameter sätts till true — kommer cert-manager inte att skapa en ny nyckel och varna dig om att ingen kontonyckel tillhandahölls.

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

Föredragen kedja

29 september Let’s Encrypt kommer att gå över till egen root certifikatmyndighet ISRG Root. Certifikaten med korssigneringar kommer att bytas ut mot Identrust. Denna ändring kräver inga justeringar i inställningarna för cert-manager, alla uppdaterade eller nya certifikat som utfärdas efter detta datum kommer att använda den nya rot CA.

Let’s Encrypt signerade redan certifikat med denna CA och erbjuder dem som "alternativ certifikatkedja" via ACME. I denna version av cert-manager finns det möjlighet att ange åtkomst till dessa kedjor i utgivarinställningarna. I parametern preferredChain kan namnet på den använda CA anges varifrån certifikatet kommer att utfärdas. Om det finns ett CA-certifikat som matchar begäran kommer det att utfärda dig ett certifikat. Observera att detta är den föredragna metoden; om inget hittas kommer ett standardcertifikat att utfärdas. Detta säkerställer att du ändå kommer att få en uppdatering av ditt certifikat efter att den alternativa kedjan har tagits bort på ACME-utgivarens sida.

Idag kan certifikat signeras av ISRG Root, så här:

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

Om du föredrar att behålla kedjan IdenTrust — ställ in denna parameter på 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"

Observera att denna root certifikatmyndighet snart kommer att föråldras, Let’s Encrypt kommer att hålla denna kedja aktiv fram till 29 september 2021.

Källa: habr.com