🥇 cert-manager 1.0 lansert

Spør du en erfaren, vis ingeniør om hva han mener om cert-manager og hvorfor alle bruker det, vil han se oppgitt ut, omfavne deg fortrolig og si: "Alle bruker det fordi det ikke er noen fornuftige alternativer. Våre mus gråter, stikker seg, men fortsetter å leve med denne kaktusen. Hvorfor elsker vi det? Fordi det fungerer. Hvorfor liker vi det ikke? Fordi det stadig kommer nye versjoner med nye funksjoner. Og vi må oppdatere klyngen gang på gang. Gamle versjoner slutter å fungere fordi det er en konspirasjon og stort mystisk sjamanisme."

Men utviklerne forsikrer at med cert-manager 1.0 vil alt endre seg.

Skal vi tro på det?

Cert-manager er den "nære" kontrolløren for administrering av sertifikater i Kubernetes. Med det kan man utstede sertifikater fra forskjellige kilder: Let’s Encrypt, HashiCorp Vault, Venafi, par med nøkler for signering og selvsignerte. Det gjør det også mulig å holde nøklene oppdatert i henhold til gyldighetsperioden og prøver å oppdatere sertifikatene automatisk på angitt tid før utløpet. Cert-manager er basert på kube-lego, og har også brukt noen teknikker fra andre lignende prosjekter, som kube-cert-manager.

Utgivelsesnotater

Med versjon 1.0 setter vi et tegn på tillit etter tre års utvikling av cert-manager-prosjektet. I løpet av denne tiden har det utviklet seg betydelig i funksjonalitet og stabilitet, men mest av alt i fellesskapet. I dag ser vi mange mennesker bruke det for å beskytte sine Kubernetes-klynger, og de implementerer det i forskjellige deler av økosystemet. I de siste 16 utgivelsene har mange feil blitt rettet. Og det som måtte brytes, er brutt. Flere forbedringer av API har forbedret samhandlingen med brukerne. Vi har løst 1500 problemer på GitHub med enda flere forespørsmål om sammenslåing fra 253 fellesskapsbidragsytere.

Med utgivelsen av 1.0 erklærer vi offisielt at cert-manager er et modent prosjekt. Vi lover også å opprettholde API-kompatibilitet. v1.

En stor takk til alle som har hjulpet oss med å utvikle cert-manager i løpet av disse tre årene! Måtte versjon 1.0 bli den første av mange store prestasjoner i fremtiden.

Utgivelsen av 1.0 er en stabil utgivelse med flere prioriterte områder:

v1 API;
Laget kubectl cert-manager status, for hjelp ved feilsøking;
Bruk av de nyeste stabile Kubernetes APIene;
Forbedret logging;
Forbedringer av ACME.

Før oppdateringen, vær sikker på å lese oppdateringsnotatene.

API v1

Versjon v0.16 fungerte med API v1beta1. Dette introduserte noen strukturelle endringer, samt forbedret dokumentasjonen for API-feltene. Versjon 1.0 bygger på dette med API v1. Denne API-en er vår første stabile, samtidig som vi allerede har gitt garantier for kompatibilitet, men med API v1 lover vi å opprettholde kompatibilitet i mange år fremover.

Endringene som er gjort (merk: våre konverteringsverktøy vil ta seg av alt for deg):

Certificate:

emailSANs heter nå emailAddresses
uriSANs — uris

Disse endringene tilfører kompatibilitet med andre SAN (subject alt names, translator's note), samt med Go API. Vi fjerner dette begrepet fra vår API.

Oppdatering

Hvis du bruker Kubernetes 1.16+ — vil konverterende webhooks la deg arbeide sømløst med versjoner av API v1alpha2, v1alpha3, v1beta1 og v1. Med dem kan du bruke den nye API-versjonen uten endring eller omdisponering av dine gamle ressurser. Vi anbefaler sterkt å oppdatere manifestene til API v1, ettersom tidligere versjoner snart vil bli utdaterte. Brukere legacy av versjonen cert-manager vil fortsatt ha tilgang bare til v1, trinn for oppdatering kan finnes her.

Teamet kubectl cert-manager status

Med de nye forbedringene i vårt tillegg til kubectl har det blitt lettere å utforske problemer knyttet til utsendelse av sertifikater. kubectl cert-manager status gir nå mye mer informasjon om hva som skjer med sertifikatene, samt viser sertifikatutsendelsesstadiet.

Etter installasjonen av tillegget kan du kjøre kubectl cert-manager status certificate, som vil føre til søk etter sertifikatet med det angitte navnet og eventuelle relaterte ressurser, som CertificateRequest, Secret, Issuer, samt Order og Challenges i tilfelle bruk av sertifikater fra ACME.

Eksempel på feilsøking av et sertifikat som ikke er klart:

$ kubectl cert-manager status certificate acme-certificate

Navn: acme-certificate
Namespace: default
Opprettet: 2020-08-21T16:44:13+02:00
Forhold:
  Klar: False, Årsak: DoesNotExist, Melding: Utsteder sertifikat som hemmelighet finnes ikke
  Utsteder: True, Årsak: DoesNotExist, Melding: Utsteder sertifikat som hemmelighet finnes ikke
DNS-navn:
- example.com
Hendelser:
  Type    Årsak     Alder   Fra          Melding
  ----    ------     ----  ----          -------
  Normal  Utsteder    18m   cert-manager  Utsteder sertifikat som hemmelighet finnes ikke
  Normal  Generert  18m   cert-manager  Lagret ny privat nøkkel i midlertidig hemmelighetsressurs "acme-certificate-tr8b2"
  Normal  Forespurt  18m   cert-manager  Opprettet ny CertificateRequest-ressurs "acme-certificate-qp5dm"
Utsteder:
  Navn: acme-issuer
  Type: Utsteder
  Forhold:
    Klar: True, Årsak: ACMEAccountRegistered, Melding: ACME-kontoen ble registrert hos ACME-serveren
feil ved søk etter hemmelighet "acme-tls": hemmeligheter "acme-tls" ikke funnet
Ikke før: 
Ikke etter: 
Fornyelsestidspunkt: 
CertificateRequest:
  Navn: acme-certificate-qp5dm
  Namespace: default
  Forhold:
    Klar: False, Årsak: Ventende, Melding: Venter på sertifikatutstedelse fra ordre default/acme-certificate-qp5dm-1319513028: "pending"
  Hendelser:
    Type    Årsak        Alder   Fra          Melding
    ----    ------        ----  ----          -------
    Normal  OrdreOpprettet  18m   cert-manager  Opprettet ordre ressurse default/acme-certificate-qp5dm-1319513028
Ordre:
  Navn: acme-certificate-qp5dm-1319513028
  Tilstand: ventende, Årsak:
  Autorisasjoner:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifier: example.com, Initial Tilstand: ventende, Wildcard: false
Utfordringer:
- Navn: acme-certificate-qp5dm-1319513028-1825664779, Type: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Nøkkel: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Tilstand: ventende, Årsak: feil ved henting av clouddns-tjenestekonto: hemmelighet "clouddns-accoun" ikke funnet, Behandling: true, Presentert: false

Kommandoen kan også hjelpe med å lære mer om innholdet i sertifikatet. Eksempel på detaljer for sertifikat utstedt av Letsencrypt:

$ kubectl cert-manager status certificate example
Navn: eksempel
[...]
Hemmelighet:
  Navn: eksempel
  Utsteder Land: US
  Utsteder Organisasjon: Let's Encrypt
  Utsteder Fellesnavn: Let's Encrypt Authority X3
  Nøkkelbruk: Digital Signatur, Nøkkelinnkapsling
  Utvidede Nøkkelbruk: Serverautentisering, Klientautentisering
  Offentlig Nøkkelalgoritme: RSA
  Signaturalgoritme: SHA256-RSA
  Emnes Nøkkel-ID: 65081d98a9870764590829b88c53240571997862
  Autoritet Nøkkel-ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Serienummer: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Hendelser:  
Ikke før: 2020-06-02T04:29:56+02:00
Ikke etter: 2020-08-31T04:29:56+02:00
Fornyelsestidspunkt: 2020-08-01T04:29:56+02:00
[...]

Bruken av de nyeste stabile API-ene i Kubernetes

Cert-manager var en av de første som implementerte Kubernetes CRDs. Dette, samt vår støtte for Kubernetes-versjoner opp til 1.11, førte til at vi måtte støtte utdaterte apiextensions.k8s.io/v1beta1 for våre CRD-er, samt admissionregistration.k8s.io/v1beta1 for våre webhooks. Nå er de utdaterte og vil bli fjernet i Kubernetes fra versjon 1.22. Med vår 1.0 tilbyr vi nå full støtte apiextensions.k8s.io/v1 og admissionregistration.k8s.io/v1 for Kubernetes 1.16 (der de ble lagt til) og nyere. For brukere av tidligere versjoner fortsetter vi å tilby støtte v1beta1 i vår legacy versjon.

Forbedret logging

I denne versjonen har vi oppdatert biblioteket for logging til klog/v2, som brukes i Kubernetes 1.19. Vi sjekker også hver logg vi skriver, for å tildele den riktig nivå. Vi har fulgt veiledningen fra Kubernetes. Det er fem (faktisk — seks, translator's note) nivåer av logging, begynner med Feil (nivå 0), som bare viser viktige feil, og slutter med Sporing (nivå 5), som vil hjelpe deg med å forstå nøyaktig hva som skjer. Denne endringen har redusert mengden av logger, dersom du ikke trenger feilsøkingsinformasjon ved arbeid med cert-manager.

Tips: som standard fungerer cert-manager på nivå 2 (Informasjon), du kan overstyre dette ved å bruke global.logLevel i Helm-chartet.

Merk: visning av logger er den siste utvei ved feilsøking. For mer informasjon kan du se på vår veiledning.

N.B. redaktør: For å lære mer om hvordan dette fungerer under panseret i Kubernetes, få verdifulle råd fra praktiserende lærere, samt kvalitetsstøtte fra kundeservice, kan du delta i online-intensivene Kubernetes Grunnkurs, som finner sted 28.-30. september, og Kubernetes Mega, som finner sted 14.-16. oktober.

Forbedringer av ACME

Den mest vanlige bruken av cert-manager er sannsynligvis knyttet til utstedelse av sertifikater fra Let’s Encrypt ved hjelp av ACME. Versjon 1.0 er bemerkelsesverdig med bruk av tilbakemeldinger fra fellesskapet for å legge til to små, men viktige forbedringer i vår ACME-utsteder.

Deaktivering av opprettelse av kontonøkkel

Hvis du bruker ACME-sertifikater i stor skala, bruker du sannsynligvis samme konto på flere klynger, slik at begrensningene for sertifikatutstedelse gjelder for dem alle. Dette har allerede vært mulig i cert-manager ved å kopiere hemmeligheten angitt i privateKeySecretRef. Denne bruken var ganske buggy, ettersom cert-manager prøvde å være nyttig og gledelig opprettet en ny kontonøkkel hvis den ikke ble funnet. Derfor har vi lagt til disableAccountKeyGeneration, for å beskytte deg mot slik oppførsel, hvis du setter dette alternativet til true — cert-manager vil ikke opprette en nøkkel og varsle deg om at den ikke har fått en kontonøkkel.

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

Foretrukket kjede

29. september Let’s Encrypt vil overgå til eget rotsertifikatsenter ISRG Root. Sertifikater med kryss-signering vil bli erstattet med Identrust. Denne endringen krever ingen justeringer i cert-manager-innstillingene, alle oppdaterte eller nye sertifikater utstedt etter denne datoen vil bruke den nye rot-CA.

Let’s Encrypt signerer allerede sertifikater ved bruk av denne CA-en og tilbyr dem som "alternativ sertifikatkjede" gjennom ACME. I denne versjonen av cert-manager er det mulig å spesifisere tilgang til disse kjedene i issuer-innstillingene. I parameteren preferredChain kan du angi navnet på CA-en som brukes til å utstede sertifikatet. Hvis det er tilgjengelig et CA-sertifikat som samsvarer med forespørselen, vil det gi deg sertifikatet. Vær oppmerksom på at dette er det foretrukne alternativet; hvis ingenting bli funnet, vil det bli utstedt et standardsertifikat. Dette vil garantere at du fortsatt kan oppdatere sertifikatet ditt etter fjerning av den alternative kjeden på siden av ACME issuer.

Fra i dag kan du få sertifikater signert ISRG Root, slik:

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

Hvis du foretrekker å beholde kjeden IdenTrust — sett dette parameteret til 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"

Vær oppmerksom på at denne rot-sertifikatsenter snart vil bli foreldet, Let’s Encrypt vil støtte denne kjeden til 29. september 2021.

Kilde: habr.com