Spørger man en erfaren, vidende ingeniør, hvad han mener om cert-manager, og hvorfor alle bruger det, vil han sukke, give et fortroligt kram og træt sige: «Alle bruger det, fordi der ikke er nogen ordentlige alternativer. Vore mus græder, stikker sig, men lever videre med denne kaktus. Hvorfor elsker vi det? Fordi det fungerer. Hvorfor elsker vi det ikke? Fordi der konstant kommer nye versioner, der bruger nye funktioner. Og vi skal gang på gang opdatere klyngen. Gamle versioner stopper med at fungere, fordi der er en konspiration og stor mystisk trolddom».
Men udviklerne forsikrer, at med cert-manager 1.0 vil alt ændre sig.
Skal vi tro på det?
Cert-manager er den «native» controller til certifikatstyring i Kubernetes. Det muliggør udstedelse af certifikater fra forskellige kilder: Let’s Encrypt, HashiCorp Vault, Venafi, par af nøgler til signering og selv-signering. Det holder også nøglerne ajour med hensyn til gyldighed, og forsøger automatisk at opdatere certifikaterne inden for en angivet tid før deres udløb. Cert-manager er baseret på kube-lego og har også taget nogle tricks fra andre lignende projekter, såsom kube-cert-manager.
Udgivelsesnoter
Med version 1.0 sætter vi et tillidsmærke for de tre år, cert-manager projektet har været under udvikling. I løbet af denne tid har det udviklet sig betydeligt i funktionalitet og stabilitet, men mest af alt i samfundet. I dag ser vi, hvordan mange mennesker bruger det til at beskytte deres Kubernetes-klynger og implementere det i forskellige dele af økosystemet. I de seneste 16 udgivelser er der blevet rettet utallige fejl. Og det, der skulle brydes, er blevet brudt. Flere tilgangsmetoder til arbejdet med API'et har forbedret dets interaktion med brugerne. Vi har løst 1500 problemer på GitHub med endnu flere pull-requests fra 253 medlemmer af fællesskabet.
Ved at udgive 1.0 erklærer vi officielt, at cert-manager er et modent projekt. Vi lover også at opretholde kompatibilitet med vores API. v1.
En stor tak til alle, der har hjulpet os med at udvikle cert-manager i de tre år! Må version 1.0 være den første af mange fremtidige store præstationer.
Udgivelsen 1.0 er en stabil version med nogle prioriterede retninger:
v1API;Kommandoen
kubectl cert-manager status, til hjælp ved fejlanalyse;Brug af de nyeste stabile Kubernetes API'er;
Forbedret logning;
Forbedringer af ACME.
Før opdateringen, læs venligst opdateringsnoterne.
API v1
Version v0.16 arbejdede med API v1beta1. Dette tilføjede nogle strukturelle ændringer samt forbedrede dokumentationen for API-felterne. Version 1.0 bygger på det hele ved hjælp af API v1. Dette API er vores første stabile, samtidig har vi allerede givet garantier for kompatibilitet, men med API v1 lover vi at støtte kompatibilitet i årevis fremover.
Foretagne ændringer (bemærk: vores konverteringsværktøjer vil tage sig af alt for dig):
Certifikat:
emailSANshedder nuemailAddressesuriSANs—uris
Disse ændringer tilføjer kompatibilitet med andre SAN (subject alt names, oversætterens bemærkning), samt med Go API. Vi fjerner denne betegnelse fra vores API.
Opdatering
Hvis du bruger Kubernetes 1.16+ — konverterende webhooks vil give dig mulighed for at arbejde sømløst og samtidig med versioner af API v1alpha2, v1alpha3, v1beta1 og v1. Med deres hjælp vil du kunne bruge den nye version af API uden at ændre eller genudførelse af dine gamle ressourcer. Vi anbefaler kraftigt at opdatere manifestationerne til API v1, da tidligere versioner snart vil blive erklæret forældede. Brugere legacy af cert-manager version vil stadig have adgang til v1, opdateringstrinene kan findes .
Team kubectl cert-manager status
Med nye forbedringer i vores udvidelse til kubectl det er blevet lettere at undersøge problemer relateret til udstedelse af certifikater. kubectl cert-manager status nu giver meget mere information om, hvad der sker med certifikaterne, og viser også trin i udstedelsesprocessen.
Efter installationen af udvidelsen kan du køre kubectl cert-manager status certificate, hvilket vil medføre, at certifikatet med det angivne navn og eventuelle relaterede ressourcer som CertificateRequest, Secret, Issuer samt Order og Challenges i tilfælde af brug af certifikater fra ACME søges.
Eksempel på fejlfinding af et endnu ikke klarlagt certifikat:
$ kubectl cert-manager status certificate acme-certificate
Navn: acme-certificate
Namespace: default
Oprettet: 2020-08-21T16:44:13+02:00
Betingelser:
Klar: False, Årsag: DoesNotExist, Besked: Udstedelse af certifikat som Secret eksisterer ikke
Udstedelse: True, Årsag: DoesNotExist, Besked: Udstedelse af certifikat som Secret eksisterer ikke
DNS Navne:
- example.com
Begivenheder:
Type Årsag Alder Fra Besked
---- ------ ---- ---- -------
Normal Udstedelse 18m cert-manager Udstedelse af certifikat som Secret eksisterer ikke
Normal Genereret 18m cert-manager Ny privat nøgle gemt i midlertidig Secret ressource "acme-certificate-tr8b2"
Normal Anmodet 18m cert-manager Oprettet ny CertificateRequest ressource "acme-certificate-qp5dm"
Udsteder:
Navn: acme-issuer
Type: Udsteder
Betingelser:
Klar: True, Årsag: ACMEAccountRegistered, Besked: ACME-kontoen blev registreret med ACME-serveren
fejl ved søgning af Secret "acme-tls": secrets "acme-tls" ikke fundet
Ikke før:
Ikke efter:
Fornyelsestid:
CertificateRequest:
Navn: acme-certificate-qp5dm
Namespace: default
Betingelser:
Klar: False, Årsag: Ventende, Besked: Venter på certifikatudstedelse fra ordre default/acme-certificate-qp5dm-1319513028: "ventende"
Begivenheder:
Type Årsag Alder Fra Besked
---- ------ ---- ---- -------
Normal OrdreOprettet 18m cert-manager Oprettet Ordre ressource default/acme-certificate-qp5dm-1319513028
Ordre:
Navn: acme-certificate-qp5dm-1319513028
Tilstand: ventende, Årsag:
Autorisationer:
URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identifier: example.com, Initial Tilstand: ventende, Wildcard: false
Udfordringer:
- Navn: acme-certificate-qp5dm-1319513028-1825664779, Type: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Nøgle: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Tilstand: ventende, Årsag: fejl ved hentning af clouddns tjenestekonto: secret "clouddns-accoun" ikke fundet, Bearbejdning: true, Præsenteret: false
Kommanden kan også hjælpe med at få flere oplysninger om indholdet af certifikatet. Eksempel på detaljer for et certifikat udstedt af Letsencrypt:
$ kubectl cert-manager status certificate example
Navn: example
[...]
Secret:
Navn: example
Udsteder Land: US
Udsteder Organisation: Let's Encrypt
Udsteder Fællesnavn: Let's Encrypt Authority X3
Nøglevusage: Digital Signature, Key Encipherment
Udvidede Nøgleanvendelser: Server Authentication, Client Authentication
Offentlig Nøglealgoritme: RSA
Signature Algorithm: SHA256-RSA
Subject Key ID: 65081d98a9870764590829b88c53240571997862
Authority Key ID: a84a6a63047dddbae6d139b7a64565eff3a8eca1
Serienummer: 0462ffaa887ea17797e0057ca81d7ba2a6fb
Begivenheder:
Ikke før: 2020-06-02T04:29:56+02:00
Ikke efter: 2020-08-31T04:29:56+02:00
Fornyelsestid: 2020-08-01T04:29:56+02:00
[...]
Brug af de nyeste stabile API'er i Kubernetes
Cert-manager var en af de første, der implementerede Kubernetes CRDs. Dette, samt vores støtte til Kubernetes versioner op til 1.11, har betydet, at vi måtte støtte en forældet apiextensions.k8s.io/v1beta1 for vores CRD, samt admissionregistration.k8s.io/v1beta1 for vores webhooks. De er nu forældede og vil blive fjernet i Kubernetes fra version 1.22. Med vores 1.0 tilbyder vi nu fuld støtte apiextensions.k8s.io/v1 og admissionregistration.k8s.io/v1 for Kubernetes 1.16 (hvor de blev tilføjet) og nyere. For brugere af tidligere versioner fortsætter vi med at tilbyde støtte v1beta1 i vores legacy version.
Forbedret logning
I denne version har vi opdateret logningsbiblioteket til klog/v2, som anvendes i Kubernetes 1.19. Vi tjekker også hver log, vi skriver, for at tildele den et passende niveau. Vi har fulgt . Der er fem (faktisk seks, oversætterens bemærkning) logningsniveauer, der starter med Fejl (niveau 0), som kun viser vigtige fejl, og slutter med Trace (niveau 5), som hjælper dig med at forstå præcist, hvad der sker. Med denne ændring har vi reduceret antallet af logfiler, hvis du ikke har brug for fejlfinding information, når du arbejder med cert-manager.
Tip: som standard kører cert-manager på niveau 2 (Info), og du kan overskrive dette ved at bruge global.logLevel i Helm-chartet.
Bemærk: logvisning er en sidste ressource ved fejlfinding. For yderligere information, se vores .
N.B. redaktør: For at lære mere om, hvordan dette fungerer under motorhjelmen i Kubernetes, få værdifulde tips fra praktiske undervisere, samt kvalitets teknisk support, kan du deltage i online-intensiverne , der finder sted fra den 28.-30. september, og , der finder sted fra den 14.-16. oktober.
Forbedringer af ACME
Den mest almindelige anvendelse 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 for at inkludere feedback fra samfundet for at tilføje to små, men vigtige forbedringer til vores ACME issuer.
Deaktivering af oprettelse af kontonøgle
Hvis du bruger ACME-certifikater i store mængder, bruger du sandsynligvis den samme konto på tværs af flere klynger, så dine udstedelsesgrænser vil gælde for alle dem. Dette var allerede muligt i cert-manager ved at kopiere den hemmelighed, der er angivet i privateKeySecretRef. Denne brugssituation var ret buggy, da cert-manager forsøgte at være nyttig og gladeligt oprettede en ny kontonøgle, hvis den ikke kunne finde den. Derfor har vi tilføjet disableAccountKeyGeneration, for at beskytte dig mod denne adfærd; ved at indstille denne parameter til true — vil cert-manager ikke oprette en nøgle og advare dig om, at der ikke blev givet 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 Let’s Encrypt til et eget rodcertifikatcenter ISRG Root. Certifikater med krydssignaturer vil blive erstattet med Identrust. Denne ændring kræver ikke ændringer i cert-manager indstillingerne; alle opdaterede eller nye certifikater, der udstedes efter denne dato, vil bruge det nye rod CA.
Let’s Encrypt underskriver allerede certifikater ved hjælp af denne CA og tilbyder dem som "alternativ certifikatkæde" via ACME. I denne version af cert-manager er der en mulighed for at angive adgang til disse kæder i udstederens indstillinger. I parameteren preferredChain kan du angive navnet på den CA, der vil udstede certifikatet. Hvis et CA-certifikat, der svarer til forespørgslen, er tilgængeligt, vil det udstede dig et certifikat. Vær opmærksom på, at dette er den foretrukne mulighed; hvis intet findes, vil der blive udstedt et standardcertifikat. Dette sikrer, at du stadig kan opdatere dit certifikat efter fjernelse af den alternative kæde fra ACME-udstederen.
Allerede i dag kan du få certifikater underskrevet ISRG Root, således:
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 bevare kæden IdenTrust — sæt 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, at dette rodcertifikatcenter snart vil blive forældet; Let’s Encrypt vil holde denne kæde aktiv indtil 29. september 2021.
Kilde: habr.com
