🥇 Megjelent a Cert-Manager 1.0

Ha megkérdezünk egy tapasztalt, bölcs mérnököt, mit gondol a cert-managerről, és miért használja mindenki, akkor a szakember felsóhajt, magabiztosan megöleli, és fáradtan azt mondja: „Mindenki használja, mert nincs értelmes alternatíva. Egereink sírnak, szurkálnak, de továbbra is együtt élnek ezzel a kaktusszal. Miért szeretünk? Mert működik. Miért nem szeretünk? Mert folyamatosan jönnek ki új verziók, amelyek új funkciókat használnak. És újra és újra frissítenie kell a fürtöt. A régi verziók pedig leállnak, mert van egy összeesküvés és egy nagy titokzatos sámánizmus.

De a fejlesztők ezt állítják cert-manager 1.0 minden meg fog változni.

Elhisszük?

A Cert-manager a natív Kubernetes tanúsítványkezelési vezérlő. Különféle forrásokból származó tanúsítványok kibocsátására használható: Let's Encrypt, HashiCorp Vault, Venafi, aláírási és önaláírt kulcspárok. Lehetővé teszi azt is, hogy a kulcsokat a lejárati dátumig naprakészen tartsa, és a tanúsítványokat egy adott időpontban, lejáratuk előtt automatikusan megújítja. A Cert-manager a kube-lego-n alapul, és más hasonló projektekből, például a kube-cert-managerből is használt néhány trükköt.

Kiadási megjegyzések

Az 1.0-s verzióval a tanúsítványkezelő projekt három évnyi fejlesztése iránti bizalmat tanúsítjuk. Ez idő alatt jelentősen fejlődött a funkcionalitás és a stabilitás, de leginkább a közösség terén. Ma azt látjuk, hogy sokan használják Kubernetes-fürtjeik védelmére, valamint az ökoszisztéma különböző részein. Az elmúlt 16 kiadásban sok hibát javítottak. És amit el kellett törni, az eltört. Az API-val végzett munka során tett látogatások javították a felhasználókkal való interakciót. 1500 problémát oldottunk meg a GitHubon a közösség 253 tagjának további lehívási kérelmeivel.

Az 1.0 kiadásával hivatalosan kijelentjük, hogy a cert-manager kiforrott projekt. Azt is ígérjük, hogy API-nkat kompatibilisek maradunk v1.

Nagyon köszönjük mindenkinek, aki ebben a három évben segített bennünket, hogy tanúsítvány-menedzserré váljunk! Legyen az 1.0-s verzió az első a sok jövőbeli nagy dolog közül.

Az 1.0-s kiadás egy stabil kiadás, több prioritási területtel:

v1 API;
Csapat kubectl cert-manager status, problémaelemzés segítése;
A legújabb stabil Kubernetes API-k használata;
Továbbfejlesztett fakitermelés;
ACME fejlesztések.

Frissítés előtt feltétlenül olvassa el a frissítési megjegyzéseket.

API v1

A 0.16-os verzió együttműködött az API-val v1beta1. Ez hozzáadott néhány szerkezeti változtatást, és javította az API-meződokumentációt is. Az 1.0-s verzió erre épül API-val v1. Ez az API az első stabil API-nk, ugyanakkor már kompatibilitási garanciát adtunk, de az API-val v1 megígérjük, hogy a kompatibilitást az elkövetkező években is fenntartjuk.

Változtatások (megjegyzés: konverziós eszközeink mindent elintéznek helyetted):

tanúsítvány:

emailSANs most hívják emailAddresses
uriSANs - uris

Ezek a változtatások kompatibilitást adnak más SAN-okkal (alanyi alternatív nevek, kb. fordító), valamint a Go API-val. Ezt a kifejezést eltávolítjuk API-nkból.

frissítés

Ha Kubernetes 1.16+ verziót használ, a webhookok konvertálása lehetővé teszi, hogy egyidejűleg és zökkenőmentesen dolgozzon az API-verziókkal v1alpha2, v1alpha3, v1beta1 и v1. Ezekkel a régi erőforrások megváltoztatása vagy újratelepítése nélkül használhatja majd az API új verzióját. Erősen javasoljuk, hogy frissítse a jegyzékeit az API-ra v1, mivel a korábbi verziók hamarosan megszűnnek. Felhasználók legacy a cert-manager verziói továbbra is csak a v1, a frissítés lépései megtalálhatók itt.

kubectl cert-manager status parancs

A bővítményünk új fejlesztéseivel kubectl könnyebbé vált a tanúsítványkiadás elmulasztásával kapcsolatos problémák kivizsgálása. kubectl cert-manager status most sokkal több információt ad arról, hogy mi történik a tanúsítványokkal, és megmutatja a tanúsítványkibocsátási szakaszt is.

A bővítmény telepítése után futhat kubectl cert-manager status certificate <имя-сертификата>, amely megkeresi a megadott névvel ellátott tanúsítványt és a kapcsolódó erőforrásokat, például a CertificateRequest, Secret, Issuer és Order and Challenges, ha az ACME tanúsítványait használja.

Példa egy még nem kész tanúsítvány hibakeresésére:

$ 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

A parancs segíthet abban is, hogy többet tudjon meg a tanúsítvány tartalmáról. Részletes példa a Letsencrypt által kiadott tanúsítványra:

$ 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
[...]

A legújabb stabil Kubernetes API-k használata

A Cert-manager az elsők között vezette be a Kubernetes CRD-ket. Ez, valamint a Kubernetes 1.11-ig terjedő verzióinak támogatása azt jelentette, hogy támogatnunk kell az örökséget apiextensions.k8s.io/v1beta1 CRD-jeink számára is admissionregistration.k8s.io/v1beta1 webhooink számára. Ezek már elavultak, és eltávolítják a Kubernetes 1.22-es verziójából. Az 1.0-s verziónkkal teljes körű támogatást nyújtunk apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 Kubernetes 1.16 (ahova hozzáadták) és újabb verziókhoz. A korábbi verziók felhasználóinak továbbra is támogatást nyújtunk v1beta1 miénkben legacy verziók.

Továbbfejlesztett naplózás

Ebben a kiadásban a naplózási könyvtárat a következőre frissítettük klog/v2, a Kubernetes 1.19-ben használatos. Minden írt folyóiratot átnézünk, hogy megbizonyosodjunk arról, hogy a megfelelő szinthez vannak rendelve. Minket ez irányított útmutatást a Kubernetestől. Öt van (valójában hat, kb. fordító) naplózási szintek kezdődően Error (0. szint), amely csak a fontos hibákat írja ki, és ezzel végződik Trace (5. szint), amely segít pontosan tudni, hogy mi történik. Ezzel a változtatással csökkentettük a naplók számát, ha nincs szüksége hibakeresési információkra a cert-manager futtatásakor.

Tipp: a tanúsítványkezelő alapértelmezés szerint a 2. szinten fut (Info), ezt a használatával felülbírálhatja global.logLevel a Helmchartban.

Megjegyzés: A naplók megtekintése az utolsó lehetőség a hibaelhárítás során. További információkért tekintse meg a mi vezetés.

A szerkesztő n.b.: Ha többet szeretne megtudni arról, hogyan működik mindez a Kubernetes motorháztetője alatt, értékes tanácsokat kaphat gyakorló tanároktól, valamint minőségi technikai támogatást kaphat, részt vehet az online intenzív tanfolyamokon. Kubernetes bázis, amely szeptember 28-30 között kerül megrendezésre, ill Kubernetes Megaamely október 14-16.

ACME fejlesztések

A cert-manager leggyakoribb használata valószínűleg a Let's Encrypt által ACME használatával történő tanúsítványok kiadásával kapcsolatos. Az 1.0-s verzió a közösségi visszajelzések felhasználásával két apró, de fontos fejlesztéssel egészítette ki ACME-kibocsátónkat.

Fiókkulcs-generálás letiltása

Ha nagy mennyiségben használ ACME-tanúsítványokat, akkor valószínűleg ugyanazt a fiókot fogja használni több fürtben, így a tanúsítványkibocsátási korlátozások mindegyikre vonatkozni fognak. Ez már a cert-managerben is lehetséges volt a -ban megadott titok másolásakor privateKeySecretRef. Ez a használati eset meglehetősen hibás volt, mivel a tanúsítványkezelő igyekezett segítőkész lenni, és boldogan létrehozott egy új fiókkulcsot, ha nem talált. Ezért adtuk hozzá disableAccountKeyGenerationhogy megvédje magát ettől a viselkedéstől, ha ezt az opciót állítja be true - a cert-manager nem generál kulcsot, és figyelmezteti, hogy nem kapott fiókkulcsot.

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

Preferált lánc

Szeptember 29. Titkosítsuk el fog múlni a saját gyökér CA-jához ISRG Root. A kereszten aláírt tanúsítványok helyébe a Identrust. Ez a módosítás nem igényli a tanúsítványkezelő beállításainak módosítását, az ezen dátum után kiadott összes frissített vagy új tanúsítvány az új gyökér CA-t fogja használni.

A Let's Encrypt már aláírja a tanúsítványokat ezzel a CA-val, és „alternatív tanúsítványláncként” kínálja őket az ACME-n keresztül. A cert-manager ezen verziójában lehetőség van ezekhez a láncokhoz való hozzáférés beállítására a kibocsátó beállításaiban. A paraméterben preferredChain megadhatja a használatban lévő CA nevét, amellyel a tanúsítvány kiadásra kerül. Ha rendelkezésre áll a kérésnek megfelelő CA-tanúsítvány, akkor tanúsítványt állít ki Önnek. Kérjük, vegye figyelembe, hogy ez az előnyben részesített lehetőség, ha nem talál semmit, akkor alapértelmezett tanúsítvány kerül kiadásra. Ez biztosítja, hogy továbbra is megújítsa a tanúsítványt az ACME kibocsátói oldalon lévő alternatív lánc törlése után is.

Már ma is megkaphatja az általa aláírt tanúsítványokat ISRG Root, Így:

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

Ha inkább elhagyja a láncot IdenTrust - állítsa be ezt az opciót 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"

Felhívjuk figyelmét, hogy ez a gyökér CA hamarosan elavulttá válik, a Let's Encrypt 29. szeptember 2021-ig aktívan tartja ezt a láncot.

Forrás: will.com

A cert-manager 1.0 megjelent