🥇cert-manager 1.0 udgivet

Spørger man en erfaren, klog ingeniør, hvad han synes om cert-manager, og hvorfor alle bruger det, vil specialisten sukke, kramme ham fortroligt og sige træt: ”Alle bruger det, for der er ingen fornuftige alternativer. Vores mus græder, prikker sig selv, men fortsætter med at leve med denne kaktus. Hvorfor elsker vi? For det virker. Hvorfor elsker vi ikke? Fordi der hele tiden udgives nye versioner, der bruger nye funktioner. Og du skal opdatere klyngen igen og igen. Og de gamle versioner holder op med at virke, fordi der er en sammensværgelse og en stor mystisk shamanisme.”

Men udviklerne hævder, at med cert-manager 1.0 alt vil ændre sig.

Skal vi tro det?

Cert-manager er en indbygget Kubernetes-certifikatstyringscontroller. Det kan bruges til at udstede certifikater fra forskellige kilder: Let's Encrypt, HashiCorp Vault, Venafi, signering og selvsignerede nøglepar. Det giver dig også mulighed for at holde nøgler opdateret og forsøger automatisk at forny certifikater på et bestemt tidspunkt, før de udløber. Cert-manager er baseret på kube-lego, og brugte også nogle teknikker fra andre lignende projekter, såsom kube-cert-manager.

Udgivelses noter

Med version 1.0 sætter vi et tegn på tillid til de tre års udvikling af cert-manager-projektet. I løbet af denne tid har den udviklet sig markant i funktionalitet og stabilitet, men mest af alt i samfundet. I dag ser vi mange mennesker, der bruger det til at sikre deres Kubernetes-klynger, såvel som at implementere det i forskellige dele af økosystemet. En masse fejl er blevet rettet i de seneste 16 udgivelser. Og det, der skulle være gået i stykker, var gået i stykker. Adskillige besøg på API'en forbedrede interaktionen med brugerne. Vi har løst 1500 problemer på GitHub med endnu flere pull-anmodninger fra 253 fællesskabsmedlemmer.

Ved at udgive 1.0 erklærer vi officielt, at cert-manager er et modent projekt. Vi lover også at holde vores API kompatible v1.

Mange tak til alle, der har hjulpet os med at skabe cert-manager alle disse tre år! Lad version 1.0 være den første af mange gode ting, der kommer.

Release 1.0 er en stabil udgivelse med flere prioriterede områder:

v1 BRAND;
Team kubectl cert-manager status, for at hjælpe med at analysere problemer;
Brug af de seneste stabile Kubernetes API'er;
Forbedret logning;
ACME-forbedringer.

Sørg for at læse opdateringsbemærkningerne, før du opgraderer.

API v1

Version v0.16 fungerede med API'en v1beta1. Dette tilføjede nogle strukturelle ændringer og forbedrede også API-feltdokumentationen. Version 1.0 bygger på dette alt sammen med en API v1. Denne API er vores første stabile, samtidig har vi allerede givet kompatibilitetsgarantier, men med API v1 Vi lover at bevare kompatibiliteten i de kommende år.

Foretagne ændringer (bemærk: vores konverteringsværktøjer tager sig af alt for dig):

Certifikat:

emailSANs nu kaldet emailAddresses
uriSANs — uris

Disse ændringer tilføjer kompatibilitet med andre SAN'er (alt andet emnenavne, ca. oversætter), samt med Go API. Vi fjerner dette udtryk fra vores API.

Opdater

Hvis du bruger Kubernetes 1.16+ - vil konvertering af webhooks give dig mulighed for at arbejde med API-versioner samtidigt og problemfrit v1alpha2, v1alpha3, v1beta1 и v1. Med dem kan du bruge den nye version af API'en uden at ændre eller omdistribuere dine gamle ressourcer. Vi anbefaler kraftigt at opgradere dine manifester til API'en v1, da tidligere versioner snart vil blive udfaset. Brugere legacy versioner af cert-manager vil stadig kun have adgang til v1, kan opdateringstrin findes her.

kubectl cert-manager status kommando

Med nye forbedringer i vores udvidelse til kubectl Det er blevet lettere at undersøge problemer forbundet med manglende udstedelse af certifikater. kubectl cert-manager status giver nu meget mere information om, hvad der sker med certifikater, og viser også det stadium, hvor certifikatet udstedes.

Efter installation af udvidelsen kan du køre kubectl cert-manager status certificate <имя-сертификата>, som vil søge efter certifikatet med det angivne navn og eventuelle tilknyttede ressourcer, såsom CertificateRequest, Secret, Issuer og Order and Challenges i tilfælde af certifikater fra ACME.

Et eksempel på fejlretning af et certifikat, der endnu ikke er klar:

$ 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å hjælpe dig med at lære mere om indholdet af certifikatet. Eksempeldetaljer for et certifikat udstedt af 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
[...]

Udnyt de seneste stabile Kubernetes API'er

Cert-manager var en af de første til at implementere Kubernetes CRD'er. Dette kombineret med vores understøttelse af Kubernetes-versioner op til 1.11 betød, at vi var nødt til at understøtte ældre apiextensions.k8s.io/v1beta1 også for vores CRD'er admissionregistration.k8s.io/v1beta1 til vores webhooks. Disse er nu forældet og vil blive fjernet i Kubernetes fra og med version 1.22. Med vores 1.0 tilbyder vi nu fuld support apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 til Kubernetes 1.16 (hvor de blev tilføjet) og senere. For brugere af tidligere versioner tilbyder vi fortsat support v1beta1 i vores legacy versioner.

Forbedret logning

I denne version har vi opdateret logbiblioteket til klog/v2, brugt i Kubernetes 1.19. Vi gennemgår også hvert magasin, vi skriver, for at sikre, at det er tildelt det passende niveau. Vi blev guidet af dette vejledning fra Kubernetes. Der er fem (faktisk - seks, ca. oversætter) logningsniveauer startende fra Error (niveau 0), som kun udskriver vigtige fejl, og slutter med Trace (niveau 5), som vil hjælpe dig med at finde ud af præcis, hvad der sker. Med denne ændring har vi reduceret antallet af logfiler, hvis du ikke har brug for fejlfindingsoplysninger, når du kører cert-manager.

Tip: som standard kører cert-manager på niveau 2 (Info), kan du tilsidesætte dette ved hjælp af global.logLevel i Helm chart.

Bemærk: Gennemgang af logfilerne er din sidste udvej ved fejlfinding. For mere information se vores ledelse.

Redaktørens NB: For at lære mere om, hvordan det hele fungerer under Kubernetes hætte, få værdifulde råd fra praktiserende lærere, samt teknisk support af høj kvalitet, kan du deltage i intensive onlinekurser Kubernetes Base, som finder sted 28.-30. september, og Kubernetes Mega, som finder sted 14.-16. oktober.

ACME-forbedringer

Den mest almindelige brug af cert-manager er sandsynligvis relateret til udstedelse af certifikater fra Let's Encrypt ved hjælp af ACME. Version 1.0 er bemærkelsesværdig ved at bruge community-feedback til at tilføje to små, men vigtige forbedringer til vores ACME-udsteder.

Deaktiver kontonøglegenerering

Hvis du bruger ACME-certifikater i store mængder, bruger du sandsynligvis den samme konto på flere klynger, så dine certifikatudstedelsesbegrænsninger vil gælde for dem alle. Dette var allerede muligt i cert-manager ved kopiering af hemmeligheden specificeret i privateKeySecretRef. Denne use case var ret buggy, fordi cert-manager forsøgte at være hjælpsom og gladeligt oprettede en ny kontonøgle, hvis den ikke kunne finde en. Derfor tilføjede vi disableAccountKeyGenerationfor at beskytte dig mod denne adfærd ved at indstille denne indstilling til true - cert-manager vil ikke generere en nøgle og vil advare dig om, at den ikke fik en kontonøgle.

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

Foretrukken kæde

29. september Lad os kryptere vil flytte til din egen rodcertifikatmyndighed ISRG Root. Krydssignerede certifikater vil blive erstattet med Identrust. Denne ændring kræver ikke ændringer af cert-manager-indstillingerne; alle opdaterede eller nye certifikater udstedt efter denne dato vil bruge den nye rod-CA.

Let's Encrypt signerer allerede certifikater med denne CA og tilbyder dem som en "alternativ certifikatkæde" gennem ACME. Denne version af cert-manager har mulighed for at indstille adgang til disse kæder i udstederindstillingerne. I parameteren preferredChain Du kan angive navnet på den CA, der blev brugt til at udstede certifikatet. Hvis et CA-certifikat er tilgængeligt, der matcher anmodningen, vil det udstede et certifikat til dig. Bemærk venligst, at dette er den foretrukne mulighed; hvis der ikke findes noget, vil der blive udstedt et standardcertifikat. Dette vil sikre, at du stadig vil forny dit certifikat efter sletning af den alternative kæde på ACME-udstedersiden.

I dag kan du modtage certifikater underskrevet 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 foretrækker at forlade kæden IdenTrust — indstil denne parameter 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"

Bemærk venligst, at denne rod-CA snart vil blive udfaset. Let's Encrypt holder denne kæde aktiv indtil den 29. september 2021.

Kilde: www.habr.com

cert-manager 1.0 udgivet