🥇cert-manager 1.0 utgitt

Hvis du spør en erfaren, klok ingeniør hva han synes om cert-manager og hvorfor alle bruker den, vil spesialisten sukke, klemme ham fortrolig og trett si: «Alle bruker det, for det finnes ingen fornuftige alternativer. Musene våre gråter, stikker seg selv, men fortsetter å leve med denne kaktusen. Hvorfor elsker vi? Fordi det fungerer. Hvorfor elsker vi ikke? For det kommer stadig nye versjoner som bruker nye funksjoner. Og du må oppdatere klyngen om og om igjen. Og de gamle versjonene slutter å virke, fordi det er en konspirasjon og en stor mystisk sjamanisme.»

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

Skal vi tro det?

Cert-manager er en innebygd Kubernetes-sertifikatbehandlingskontroller. Den kan brukes til å utstede sertifikater fra ulike kilder: Let's Encrypt, HashiCorp Vault, Venafi, signering og selvsignerte nøkkelpar. Den lar deg også holde nøkler oppdatert og forsøker å automatisk fornye sertifikater på et spesifisert tidspunkt før de utløper. Cert-manager er basert på kube-lego, og brukte også noen teknikker fra andre lignende prosjekter, for eksempel kube-cert-manager.

Utgivelsesnotater

Med versjon 1.0 setter vi et tegn på tillit til de tre årene med utvikling av cert-manager-prosjektet. I løpet av denne tiden har den utviklet seg betydelig i funksjonalitet og stabilitet, men mest av alt i samfunnet. I dag ser vi mange som bruker det til å sikre Kubernetes-klynger, samt implementere det i ulike deler av økosystemet. En haug med feil har blitt fikset i de siste 16 utgivelsene. Og det som skulle ha vært ødelagt var ødelagt. Flere besøk til API forbedret interaksjonen med brukerne. Vi har løst 1500 problemer på GitHub, med enda flere pull-forespørsler fra 253 fellesskapsmedlemmer.

Ved å gi ut 1.0 erklærer vi offisielt at cert-manager er et modent prosjekt. Vi lover også å holde API-kompatible v1.

Tusen takk til alle som har hjulpet oss med å lage cert-manager alle disse tre årene! La versjon 1.0 være den første av mange flotte ting som kommer.

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

v1 BRANN;
Lag kubectl cert-manager status, for å hjelpe til med å analysere problemer;
Bruker de siste stabile Kubernetes APIene;
Forbedret logging;
ACME-forbedringer.

Sørg for å lese oppdateringsnotatene før du oppgraderer.

API v1

Versjon v0.16 fungerte med API v1beta1. Dette la til noen strukturelle endringer og forbedret også API-feltdokumentasjonen. Versjon 1.0 bygger på alt dette med en API v1. Denne APIen er vår første stabile, samtidig har vi allerede gitt kompatibilitetsgarantier, men med API v1 Vi lover å opprettholde kompatibiliteten i årene som kommer.

Endringer som er gjort (merk: konverteringsverktøyene våre tar seg av alt for deg):

Sertifikat:

emailSANs nå kalt emailAddresses
uriSANs - uris

Disse endringene legger til kompatibilitet med andre SAN-er (alt-navn for emne, ca. oversetter), så vel som med Go API. Vi fjerner denne termen fra API-en vår.

Oppdater

Hvis du bruker Kubernetes 1.16+ - konvertering av webhooks vil tillate deg å jobbe med API-versjoner samtidig og sømløst v1alpha2, v1alpha3, v1beta1 и v1. Med dem kan du bruke den nye versjonen av API-en uten å endre eller omdistribuere de gamle ressursene dine. Vi anbefaler på det sterkeste å oppgradere manifestene dine til API v1, ettersom tidligere versjoner snart vil bli avviklet. Brukere legacy versjoner av cert-manager vil fortsatt bare ha tilgang til v1, kan du finne oppdateringstrinn her.

kubectl cert-manager status kommando

Med nye forbedringer i utvidelsen vår til kubectl Det er blitt lettere å undersøke problemer knyttet til manglende utstedelse av sertifikater. kubectl cert-manager status gir nå mye mer informasjon om hva som skjer med sertifikater, og viser også på hvilket stadium sertifikatet utstedes.

Etter å ha installert utvidelsen kan du kjøre kubectl cert-manager status certificate <имя-сертификата>, som vil søke etter sertifikatet med det spesifiserte navnet og eventuelle tilknyttede ressurser, som CertificateRequest, Secret, Issuer og Order and Challenges når det gjelder sertifikater fra ACME.

Et eksempel på feilsøking av et sertifikat som ennå ikke er 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

Teamet kan også hjelpe deg med å lære mer om innholdet i sertifikatet. Eksempeldetaljer for et sertifikat utstedt 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
[...]

Utnytt de siste stabile Kubernetes APIene

Cert-manager var en av de første som implementerte Kubernetes CRD-er. Dette, kombinert med vår støtte for Kubernetes-versjoner opp til 1.11, betydde at vi måtte støtte eldre apiextensions.k8s.io/v1beta1 også for våre CRD-er admissionregistration.k8s.io/v1beta1 for våre webhooks. Disse er nå avviklet og vil bli fjernet i Kubernetes fra og med versjon 1.22. Med vår 1.0 tilbyr vi nå full støtte apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 for Kubernetes 1.16 (hvor de ble lagt til) og senere. For brukere av tidligere versjoner fortsetter vi å tilby støtte v1beta1 i vår legacy versjoner.

Forbedret logging

I denne versjonen har vi oppdatert loggbiblioteket til klog/v2, brukt i Kubernetes 1.19. Vi gjennomgår også hvert blad vi skriver for å sikre at det er tildelt riktig nivå. Vi ble veiledet av dette veiledning fra Kubernetes. Det er fem (faktisk - seks, ca. oversetter) loggingsnivåer fra Error (nivå 0), som kun skriver ut viktige feil, og ender med Trace (nivå 5), som vil hjelpe deg å finne ut nøyaktig hva som skjer. Med denne endringen har vi redusert antall logger hvis du ikke trenger feilsøkingsinformasjon når du kjører cert-manager.

Tips: som standard kjører cert-manager på nivå 2 (Info), kan du overstyre dette ved å bruke global.logLevel i Helm-diagrammet.

Merk: Gjennomgang av loggene er siste utvei ved feilsøking. For mer informasjon sjekk ut vår ledelse.

Redaktørens NB: For å lære mer om hvordan det hele fungerer under panseret til Kubernetes, få verdifulle råd fra praktiserende lærere, samt teknisk støtte av høy kvalitet, kan du ta del i intensive nettkurser Kubernetes Base, som finner sted 28.-30. september, og Kubernetes Mega, som finner sted 14.–16. oktober.

ACME-forbedringer

Den vanligste bruken av cert-manager er sannsynligvis knyttet til å utstede sertifikater fra Let's Encrypt ved hjelp av ACME. Versjon 1.0 er kjent for å bruke tilbakemelding fra fellesskapet for å legge til to små, men viktige forbedringer til ACME-utstederen vår.

Deaktiver kontonøkkelgenerering

Hvis du bruker ACME-sertifikater i store volumer, bruker du sannsynligvis den samme kontoen på flere klynger, så dine sertifikatutstedelsesbegrensninger vil gjelde for dem alle. Dette var allerede mulig i cert-manager ved kopiering av hemmeligheten spesifisert i privateKeySecretRef. Denne brukssaken var ganske buggy fordi cert-manager prøvde å være nyttig og gladelig opprettet en ny kontonøkkel hvis den ikke fant en. Derfor la vi til disableAccountKeyGenerationfor å beskytte deg mot denne oppførselen ved å sette dette alternativet til true - cert-manager vil ikke generere en nøkkel og vil advare deg om at den ikke ble gitt 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 La oss kryptere vil flytte til din egen rotsertifikatmyndighet ISRG Root. Krysssignerte sertifikater vil bli erstattet med Identrust. Denne endringen krever ikke endringer i innstillingene for cert-manager; alle oppdaterte eller nye sertifikater utstedt etter denne datoen vil bruke den nye rot-CA.

Let's Encrypt signerer allerede sertifikater med denne CA og tilbyr dem som en "alternativ sertifikatkjede" gjennom ACME. Denne versjonen av cert-manager har muligheten til å angi tilgang til disse kjedene i utstederinnstillingene. I parameteren preferredChain Du kan angi navnet på CA som ble brukt til å utstede sertifikatet. Hvis et CA-sertifikat er tilgjengelig som samsvarer med forespørselen, vil det utstede deg et sertifikat. Vær oppmerksom på at dette er det foretrukne alternativet; hvis ingenting blir funnet, vil et standardsertifikat bli utstedt. Dette vil sikre at du fortsatt vil fornye sertifikatet ditt etter å ha slettet den alternative kjeden på ACME-utstedersiden.

I dag kan du motta sertifikater signert ISRG Root, Så:

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 å forlate kjeden IdenTrust — sett denne parameteren 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-CA snart vil bli avviklet. Let's Encrypt vil holde denne kjeden aktiv frem til 29. september 2021.

Kilde: www.habr.com

cert-manager 1.0 utgitt