Nëse pyet një inxhinier me përvojë dhe të mençur se çfarë mendon për Cert-Manager dhe pse të gjithë e përdorin atë, ai do të psherëtijë, do të të përqafojë me konfidencialitet dhe do të thotë i lodhur: "Të gjithë e përdorin sepse nuk ka alternativa të arsyeshme. Minjtë tanë qajnë, shpojnë veten, por vazhdojnë të jetojnë me këtë kaktus. Pse e duam? Sepse funksionon. Pse nuk na pëlqen? Sepse versione të reja dalin vazhdimisht, duke përfshirë veçori të reja. Dhe duhet ta përditësosh grumbullin vazhdimisht. Dhe versionet e vjetra ndalojnë së funksionuari sepse ekziston një komplot dhe një shamanizëm i madh misterioz."
Por zhvilluesit sigurojnë që me menaxheri i certifikatave 1.0 gjithçka do të ndryshojë.
A do ta besojmë?
Cert-manager është një kontrollues vendas i menaxhimit të certifikatave Kubernetes. Ai mund të lëshojë certifikata nga burime të ndryshme, duke përfshirë Let's Encrypt, HashiCorp Vault, Venafi, dhe çifte çelësash si për nënshkrimin ashtu edhe për vetë-nënshkrimin. Ai gjithashtu i mban çelësat të përditësuar me periudhat e vlefshmërisë dhe përpiqet të rinovojë automatikisht certifikatat në kohë të caktuara para se të skadojnë. Cert-manager bazohet në kube-lego dhe gjithashtu huazon disa teknika nga projekte të tjera të ngjashme, të tilla si kube-cert-manager.
Shënimet e publikimit
Me versionin 1.0, po festojmë tre vjet zhvillim për projektin cert-manager. Gjatë kësaj kohe, ai është rritur ndjeshëm në funksionalitet dhe stabilitet, por mbi të gjitha, në komunitet. Sot, shohim shumë njerëz që e përdorin atë për të siguruar klasteret e tyre Kubernetes dhe për ta zbatuar atë në pjesë të ndryshme të ekosistemit. 16 versionet e fundit kanë parë rregullime të shumta gabimesh. Dhe ajo që duhej të prishej është prishur. Disa raunde pune API kanë përmirësuar përvojën e përdoruesit. Ne kemi zgjidhur 1500 probleme në GitHub, me edhe më shumë kërkesa tërheqjeje nga 253 anëtarë të komunitetit.
Duke publikuar versionin 1.0, ne zyrtarisht e shpallim cert-manager një projekt të pjekur. Gjithashtu premtojmë të ruajmë përputhshmërinë me API-në tonë. v1.
Një falënderim i madh për të gjithë ata që na ndihmuan të zhvillojmë Cert-Manager gjatë tre viteve të fundit! Versioni 1.0 le të jetë i pari nga shumë arritje të mëdha që do të vijnë.
Versioni 1.0 është një version i qëndrueshëm me disa fusha fokusi:
-
v1ZJARR; -
Ekip
kubectl cert-manager status, për të ndihmuar në analizimin e problemeve; -
Duke përdorur API-të më të fundit të qëndrueshme të Kubernetes;
-
Regjistrim i përmirësuar;
-
Përmirësime të ACME-së.
Ju lutemi sigurohuni që të lexoni shënimet e përditësimit përpara se të përditësoni.
API v1
Versioni v0.16 funksionoi me API-n v1beta1Kjo shtoi disa ndryshime strukturore dhe përmirësoi dokumentimin e fushave të API-t. Versioni 1.0 ndërtohet mbi këtë me API-n. v1Ky API është i pari ynë i qëndrueshëm, ndërsa ne kemi ofruar tashmë garanci përputhshmërie, por me API-në v1 Ne premtojmë të ruajmë përputhshmërinë për vitet që vijnë.
Ndryshimet e bëra (shënim: mjetet tona të konvertimit do të kujdesen për gjithçka për ju):
Certifikata:
-
emailSANstani quhetemailAddresses -
uriSANs-uris
Këto ndryshime shtojnë përputhshmërinë me SAN-të e tjera (emrat alternativë të subjektit, përafërsisht. përkthyes), si dhe me Go API-n. Po e heqim këtë term nga API-ja jonë.
Update
Nëse përdorni Kubernetes 1.16+, konvertimi i webhook-eve do t'ju lejojë të punoni pa probleme me versionet e API-t njëkohësisht. v1alpha2, v1alpha3, v1beta1 и v1Me këto, mund të përdorni versionin e ri të API-t pa ndryshuar ose ridislokuar burimet tuaja të vjetra. Ne ju rekomandojmë fuqimisht të përditësoni manifestet e API-t tuaj. v1, pasi versionet e mëparshme së shpejti do të hiqen nga përdorimi. Përdoruesit legacy versionet e cert-manager do të kenë ende qasje vetëm në v1, hapat e përditësimit mund të gjenden .
Komanda e statusit kubectl cert-manager
Me përmirësime të reja në zgjerimin tonë për kubectl Është bërë më e lehtë të hetohen çështjet që lidhen me moslëshimin e certifikatave. kubectl cert-manager status tani ofron shumë më tepër informacion rreth asaj që po ndodh me certifikatat dhe gjithashtu tregon fazën e lëshimit të certifikatave.
Pas instalimit të zgjerimit, mund të ekzekutoni kubectl cert-manager status certificate <имя-сертификата>, i cili do të kërkojë një certifikatë me emrin e specifikuar dhe çdo burim të lidhur me të, siç janë Kërkesa për Certifikatë, Sekreti, Lëshuesi dhe Renditja dhe Sfidat në rastin e certifikatave nga ACME.
Një shembull i debugging-ut të një certifikate që nuk është ende gati:
$ 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
Komanda mund t'ju ndihmojë gjithashtu të mësoni më shumë rreth përmbajtjes së certifikatës. Ja një shembull i detajeve për një certifikatë të lëshuar nga 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
[...]
Duke përdorur API-të më të fundit të qëndrueshme të Kubernetes
Cert-manager ishte një nga të parët që zbatoi Kubernetes CRD. Kjo, së bashku me mbështetjen tonë për versionet e Kubernetes deri në 1.11, nënkuptonte se na duhej të mbështesnim trashëgiminë. apiextensions.k8s.io/v1beta1 edhe për CRD-të tona admissionregistration.k8s.io/v1beta1 për webhook-et tona. Ato tani janë të vjetruara dhe do të hiqen në Kubernetes duke filluar nga versioni 1.22. Me versionin tonë 1.0, ne tani ofrojmë mbështetje të plotë. apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 për Kubernetes 1.16 (ku u shtuan) dhe më vonë. Ne vazhdojmë të ofrojmë mbështetje për përdoruesit e versioneve të mëparshme. v1beta1 në tonën legacy versionet.
Regjistrim i përmirësuar
Në këtë version kemi përditësuar bibliotekën e regjistrimit në klog/v2, e përdorur në Kubernetes 1.19. Ne gjithashtu shqyrtojmë çdo regjistër që shkruajmë për t'i caktuar atij nivelin e duhur. Ne përdorëm Janë pesë (në fakt gjashtë, përafërsisht. përkthyes) nivelet e regjistrimit, duke filluar nga Error (niveli 0), i cili nxjerr vetëm gabime të rëndësishme dhe përfundon me Trace (niveli 5), i cili do t'ju ndihmojë të zbuloni saktësisht se çfarë po ndodh. Me këtë ndryshim, ne kemi zvogëluar sasinë e regjistrave nëse nuk keni nevojë për informacion për debugging kur ekzekutoni cert-manager.
Këshillë: Si parazgjedhje, menaxheri i certifikatave funksionon në nivelin 2 (Info), mund ta anashkaloni këtë duke përdorur global.logLevel në tabelën Helm.
Shënim: Shikimi i regjistrave është zgjidhja e fundit kur zgjidhni probleme. Për më shumë informacion, ju lutemi shihni faqen tonë të internetit për të gjetur një zgjidhje. .
Nr.b e redaktorit.Për të mësuar më shumë rreth asaj se si funksionon gjithçka nën kapuçin e Kubernetes, për të marrë këshilla të vlefshme nga instruktorë praktikues dhe për të marrë mbështetje teknike me cilësi të lartë, mund të merrni pjesë në kurse intensive online. , e cila do të mbahet 28-30 shtator, dhe , i cili do të zhvillohet nga 14 deri në 16 tetor.
Përmirësime të ACME-së
Përdorimi më i zakonshëm i menaxherit të certifikatave është ndoshta lëshimi i certifikatave Let's Encrypt duke përdorur ACME. Versioni 1.0 është i njohur për përfshirjen e reagimeve të komunitetit në dy përmirësime të vogla, por të rëndësishme për lëshuesin tonë ACME.
Çaktivizimi i gjenerimit të çelësit të llogarisë
Nëse përdorni certifikata ACME në vëllime të mëdha, ka të ngjarë të përdorni të njëjtën llogari në disa klastera, kështu që kufizimet e lëshimit të certifikatës suaj do të zbatohen për të gjitha ato. Kjo ishte e mundur tashmë në cert-manager duke kopjuar sekretin e specifikuar në privateKeySecretRefKy rast përdorimi kishte mjaft gabime, pasi menaxheri i certifikatave u përpoq të ishte i dobishëm dhe me kënaqësi krijoi një çelës të ri llogarie nëse nuk mund të gjente një të tillë. Kjo është arsyeja pse shtuam disableAccountKeyGenerationPër t'ju mbrojtur nga kjo sjellje, nëse e vendosni këtë opsion në true — cert-manager nuk do të krijojë një çelës dhe do t'ju paralajmërojë se nuk i është dhënë një çelës llogarie.
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
privateKeySecretRef:
name: example-issuer-account-key
disableAccountKeyGeneration: false
Zinxhiri i preferuar
29 shtator Le të Enkriptojmë te autoriteti juaj i çertifikimit rrënjësor ISRG RootCertifikatat me nënshkrime të kryqëzuara do të zëvendësohen nga IdentrustKy ndryshim nuk kërkon ndonjë ndryshim në cilësimet e menaxherit të certifikatave; të gjitha certifikatat e rinovuara ose të reja të lëshuara pas kësaj date do të përdorin autoritetin e ri të certifikimit rrënjësor.
Let's Encrypt tashmë nënshkruan certifikata duke përdorur këtë CA dhe i ofron ato si një "zinxhir alternativ certifikatash" nëpërmjet ACME. Ky version i menaxherit të certifikatave ju lejon të specifikoni qasjen në këto zinxhirë në cilësimet e lëshuesit. Në parametër preferredChain Mund të specifikoni emrin e CA-së që do të lëshojë certifikatën. Nëse është e disponueshme një certifikatë CA që përputhet me kërkesën tuaj, ajo do ta lëshojë atë. Vini re se ky është opsioni i preferuar; nëse nuk gjendet asgjë, do të lëshohet certifikata e parazgjedhur. Kjo siguron që ju të mund ta rinovoni ende certifikatën tuaj pasi të fshini zinxhirin alternativ në lëshuesin ACME.
Ju mund të merrni certifikata të nënshkruara që sot ISRG Root, Kështu që:
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
preferredChain: "ISRG Root X1"
Nëse preferoni të largoheni nga zinxhiri IdenTrust - vendosni këtë parametër në 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"
Ju lutemi vini re se kjo CA rrënjë së shpejti do të hiqet nga përdorimi. Let's Encrypt do ta mbajë këtë zinxhir aktiv deri më 29 shtator 2021.
Burimi: www.habr.com
