🥇Cert-manager 1.0 är ute

Om du frågar en erfaren, klok ingenjör vad han tycker om cert-manager och varför alla använder det, då kommer specialisten att sucka, krama honom förtroendefullt och säga trött: ”Alla använder det, för det finns inga vettiga alternativ. Våra möss gråter, sticker, men fortsätter att leva med denna kaktus. Varför älskar vi? För det fungerar. Varför älskar vi inte? Eftersom det hela tiden kommer ut nya versioner som använder nya funktioner. Och du måste uppdatera klustret om och om igen. Och de gamla versionerna slutar fungera, eftersom det finns en konspiration och en stor mystisk shamanism.

Men det hävdar utvecklarna cert-manager 1.0 allt kommer att ändras.

Kommer vi att tro?

Cert-manager är den inbyggda Kubernetes certifikathanteringskontroller. Den kan användas för att utfärda certifikat från olika källor: Let's Encrypt, HashiCorp Vault, Venafi, signering och självsignerade nyckelpar. Det låter dig också hålla nycklar uppdaterade efter utgångsdatum, och försöker även automatiskt förnya certifikat vid en viss tidpunkt innan de går ut. Cert-manager är baserad på kube-lego och har även använt några knep från andra liknande projekt som kube-cert-manager.

Release Notes

Med version 1.0 sätter vi ett förtroendemärke för tre års utveckling av cert-manager-projektet. Under denna tid har det utvecklats avsevärt i funktionalitet och stabilitet, men framför allt i samhället. Idag ser vi många människor som använder det för att säkra sina Kubernetes-kluster samt distribuera det till olika delar av ekosystemet. Många buggar har åtgärdats under de senaste 16 utgåvorna. Och det som behövde brytas är trasigt. Flera besök för att arbeta med API har förbättrat interaktionen med användarna. Vi har löst 1500 253 problem på GitHub med fler pull-förfrågningar från XNUMX communitymedlemmar.

Med lanseringen av 1.0 förklarar vi officiellt att cert-manager är ett moget projekt. Vi lovar också att hålla vårt API-kompatibelt v1.

Stort tack till alla som hjälpt oss att bli cert-manager under dessa tre år! Låt version 1.0 vara den första av många stora saker som kommer.

Release 1.0 är en stabil version med flera prioriterade områden:

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

Se till att läsa uppgraderingsanmärkningarna innan du uppgraderar.

API v1

Version v0.16 fungerade med API v1beta1. Detta lade till några strukturella förändringar och förbättrade även API-fältdokumentationen. Version 1.0 bygger på detta med ett API v1. Detta API är vårt första stabila, samtidigt har vi redan gett kompatibilitetsgarantier, men med API v1 vi lovar att behålla kompatibiliteten i många år framöver.

Gjorda ändringar (obs: våra konverteringsverktyg tar hand om allt åt dig):

Certifikat:

emailSANs nu kallad emailAddresses
uriSANs - uris

Dessa ändringar lägger till kompatibilitet med andra SAN (subject alt names, cirka. översättare), såväl som med Go API. Vi tar bort denna term från vårt API.

Uppdatera

Om du använder Kubernetes 1.16+, kommer konvertering av webhooks att göra det möjligt för dig att samtidigt och sömlöst arbeta med API-versioner v1alpha2, v1alpha3, v1beta1 и v1. Med dessa kommer du att kunna använda den nya versionen av API:t utan att ändra eller omdistribuera dina gamla resurser. Vi rekommenderar starkt att du uppgraderar dina manifest till API:t v1, eftersom tidigare versioner kommer att fasas ut snart. Användare legacy versioner av cert-manager kommer fortfarande bara att ha tillgång till v1, kan uppgraderingssteg hittas här.

kubectl cert-manager statuskommando

Med nya förbättringar i vårt tillägg till kubectl det blev lättare att undersöka problemen i samband med att certifikat inte utfärdas. kubectl cert-manager status ger nu mycket mer information om vad som händer med certifikaten och visar även certifikatutfärdandestadiet.

Efter installation av tillägget kan du köra kubectl cert-manager status certificate <имя-сертификата>, som kommer att slå upp certifikatet med det angivna namnet och eventuella relaterade resurser som CertificateRequest, Secret, Issuer och Order and Challenges om du använder certifikat från ACME.

Ett exempel på felsökning av ett certifikat som ännu inte är klart:

$ 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

Kommandot kan också hjälpa dig att lära dig mer om innehållet i certifikatet. Detaljerat exempel för ett certifikat utfärdat av 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
[...]

Använder de senaste stabila Kubernetes API:erna

Cert-manager var en av de första som implementerade Kubernetes CRD:er. Detta, och vårt stöd för Kubernetes-versioner upp till 1.11, innebar att vi behövde stödja arvet apiextensions.k8s.io/v1beta1 även för våra CRD:er admissionregistration.k8s.io/v1beta1 för våra webhooks. De är nu utfasade och kommer att tas bort i Kubernetes från version 1.22. Med vår 1.0 erbjuder vi nu full support apiextensions.k8s.io/v1 и 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 support v1beta1 i vår legacy versioner.

Förbättrad loggning

I den här utgåvan har vi uppdaterat loggningsbiblioteket till klog/v2, används i Kubernetes 1.19. Vi granskar också varje journal vi skriver för att se till att den har rätt nivå. Vi vägleddes av detta vägledning från Kubernetes. Det finns fem (faktiskt sex, cirka. översättare) loggningsnivåer från Error (nivå 0), som endast skriver ut viktiga fel, och slutar med Trace (nivå 5) som hjälper dig att veta exakt vad som händer. Med denna ändring har vi minskat antalet loggar om du inte behöver felsökningsinformation när du kör cert-manager.

Tips: cert-manager körs på nivå 2 som standard (Info), kan du åsidosätta detta med hjälp av global.logLevel i Helmchart.

Obs: Att visa loggarna är den sista utvägen vid felsökning. För mer information kolla in vår ledarskap.

Redaktörens n.b.: För att lära dig mer om hur det hela fungerar under huven på Kubernetes, få värdefulla råd från praktiserande lärare, samt teknisk support av hög kvalitet, kan du delta i intensivkurser online Kubernetes bas, som kommer att hållas 28-30 september, och Kubernetes Megasom hålls 14-16 oktober.

ACME-förbättringar

Den vanligaste användningen av cert-manager är förmodligen relaterad till att utfärda certifikat från Let's Encrypt med ACME. Version 1.0 är känd för att använda communityfeedback för att lägga till två små men viktiga förbättringar till vår ACME-utgivare.

Inaktivera generering av kontonyckel

Om du använder ACME-certifikat i stora volymer kommer du sannolikt att använda samma konto på flera kluster, så dina certifikatutfärdandebegränsningar kommer att gälla för dem alla. Detta var redan möjligt i cert-manager när du kopierade hemligheten specificerad i privateKeySecretRef. Detta användningsfall var ganska buggigt, eftersom cert-manager försökte vara hjälpsam och gladeligen skapade en ny kontonyckel om den inte hittade någon. Det var därför vi lade till disableAccountKeyGenerationför att skydda dig från detta beteende om du ställer in det här alternativet till true - cert-manager kommer inte att generera en nyckel och kommer att varna dig om att den inte har försetts med en kontonyckel.

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 Låt oss kryptera kommer att passera till din egen rot-CA ISRG Root. Korssignerade certifikat kommer att ersättas av Identrust. Denna ändring kräver inga ändringar av certifikathanterarens inställningar, alla uppdaterade eller nya certifikat som utfärdas efter detta datum kommer att använda den nya rot-CA.

Let's Encrypt signerar redan certifikat med denna CA och erbjuder dem som en "alternativ certifikatkedja" via ACME. I den här versionen av cert-manager är det möjligt att ställa in åtkomst till dessa kedjor i utfärdarinställningarna. I parameter preferredChain du kan ange namnet på den CA som används, med vilken certifikatet kommer att utfärdas. Om ett CA-certifikat som matchar begäran är tillgängligt kommer det att utfärda ett certifikat till dig. Observera att detta är det föredragna alternativet, om inget hittas kommer ett standardcertifikat att utfärdas. Detta säkerställer att du fortfarande kommer att förnya ditt certifikat efter att du tagit bort den alternativa kedjan på ACME-utgivarens sida.

Redan idag kan du få certifikat signerade av ISRG Root, Alltså:

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 lämna kedjan IdenTrust - ställ in detta alternativ till 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 rot-CA kommer att fasas ut snart, Let's Encrypt kommer att hålla denna kedja aktiv till den 29 september 2021.

Källa: will.com

cert-manager 1.0 släppt