🥇Megjelent a cert-manager 1.0

Ha megkérdezzük a tapasztalt, sokat tudó mérnököt, mit gondol a cert-manager-ről és miért használja mindenki, akkor a szakember sóhajt, bizalmasan átölel, és fáradtan azt mondja: „Mindenki ezt használja, mert nincs elfogadható alternatíva. Az egereink sírnak, megnyúznak, de továbbra is élnek ezzel a kaktusszal. Miért szeretjük? Mert működik. Miért nem szeretjük? Mert folyamatosan új verziók jelennek meg, amelyek új funkciókat használnak. És újra és újra frissítenünk kell a klasztert. A régi verziók pedig megszűnnek működni, mert van egy összeesküvés és egy nagy titokzatos sámánkodás.

De a fejlesztők biztosítják, hogy a cert-manager 1.0 minden megváltozik.

Higgyünk neki?

A cert-manager a Kubernetes tanúsítványkezelés „otthoni” vezérlője. Segítségével tanúsítványokat lehet kiadni különböző forrásokból: Let’s Encrypt, HashiCorp Vault, Venafi, aláírásokhoz szükséges kulcspárok és önaláírt tanúsítványok. Ezen kívül lehetővé teszi a kulcsok aktuális állapotának fenntartását a lejárati idő szerint, és megpróbálja automatikusan frissíteni a tanúsítványokat a lejáratuk előtt megadott időben. A cert-manager a kube-legóra épül, és számos hasonló projektből, mint például a kube-cert-manager, is átvett néhány trükköt.

Kibocsátási megjegyzések

A 1.0-ás verzióval állítjuk a bizalmi jelet három év fejlesztés után a cert-manager projekten. Ez alatt az idő alatt jelentősen fejlődött a funkcionalitás és a stabilitás terén, de leginkább a közösség szempontjából. Ma látjuk, hogy sokan használják a Kubernetes klasztereik védelmére, és különböző ökoszisztémákba integrálják. Az utolsó 16 kiadásban rengeteg hibát javítottunk ki. Amit meg kellett törni — azt eltörtük. Néhány API-kkal kapcsolatos beavatkozás javította a felhasználókkal való interakciót. 1500 problémát oldottunk meg a GitHub-on, még több beolvasási kéréssel 253 közösségi tagtól.

A 1.0-ás verzió kiadásával hivatalosan is kijelentjük, hogy a cert-manager egy érett projekt. Azt is megígérjük, hogy fenntartjuk az API-nk kompatibilitását. v1.

Hatalmas köszönet mindenkinek, aki segített abban, hogy a cert-manager-t három évig fejlesszük! Az 1.0-ás verzió legyen az első sok jövőbeli nagy teljesítmény között.

Az 1.0-ás kiadás egy stabil kiadás, amely több prioritási területet foglal magában:

v1 API;
A parancs kubectl cert-manager állapot, a problémák elemzésének megkönnyítésére;
A legújabb stabil Kubernetes API-k használata;
Javított naplózás;
ACME fejlesztések.

Frissítés előtt mindenképpen olvassa el a frissítési megjegyzéseket.

API v1

A v0.16-os verzió az API-val működött v1beta1. Ez néhány struktúrábeli változást hozott, valamint javította az API mezők dokumentációját. Az 1.0-ás verzió mindezen alapokra épít az API-val v1. Ez az API az első stabil verziónk, bár már biztosítottunk kompatibilitást, de az API-val v1 megígérjük, hogy évekig fenntartjuk a kompatibilitást.

A módosítások listája (jegyzet: a konvertáló eszközeink mindent el fognak végezni az Ön számára):

Tanúsítvány:

emailSANs mostantól így hívják emailAddresses
uriSANs — uris

Ezek a változások kompatibilitást adnak más SAN-okkal (subject alt names, jegyzet: fordító), valamint a Go API-val. Ezt a kifejezést eltávolítjuk az API-nkból.

Frissítés

Ha a Kubernetes 1.16+ verzióját használja, a konvertáló webhookok lehetővé teszik, hogy egyszerre és zökkenőmentesen dolgozzon az API verziókkal v1alpha2, v1alpha3, v1beta1 és v1. Ezek segítségével új API verziót használhat anélkül, hogy meg kellene változtatnia vagy újra kellene telepítenie régi erőforrásait. Javasoljuk, hogy frissítse a manifestumokat az API-ra v1, mivel a korábbi verziók hamarosan elavulttá válnak. A felhasználók legacy a cert-manager verzióval továbbra is csak hozzáférhetnek a v1, a frissítési lépéseket itt találja itt.

A kubectl cert-manager status parancs

A legújabb fejlesztésekkel az kubectl egyszerűbb lett a tanúsítványok kiadásával kapcsolatos problémák feltárása. kubectl cert-manager állapot 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ány kiadásának lépéseit.

A bővítmény telepítése után futtathatja a kubectl cert-manager status certificate, amely megkeresi a megadott nevű tanúsítványt és minden kapcsolódó erőforrást, mint például CertificateRequest, Secret, Issuer, valamint Order és Challenges az ACME-től származó tanúsítványok esetén.

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

$ kubectl cert-manager status certificate acme-certificate

Név: acme-certificate
Namespace: default
Készítve: 2020-08-21T16:44:13+02:00
Állapotok:
  Készen: False, Ok: DoesNotExist, Üzenet: A tanúsítvány kiadása nem létezik Secretként
  Kiadás: True, Ok: DoesNotExist, Üzenet: A tanúsítvány kiadása nem létezik Secretként
DNS Nevek:
- example.com
Események:
  Típus    Ok     Kor   Ki            Üzenet
  ----    ------     ----  ----          -------
  Normális  Kiadás    18m   cert-manager  A tanúsítvány kiadása nem létezik Secretként
  Normális  Generált  18m   cert-manager  Új privát kulcs tárolása a "acme-certificate-tr8b2" ideiglenes Secret forrással
  Normális  Kért  18m   cert-manager  Új CertificateRequest forrás létrehozása "acme-certificate-qp5dm"
Kibocsátó:
  Név: acme-issuer
  Típus: Issuer
  Állapotok:
    Készen: True, Ok: ACMEAccountRegistered, Üzenet: Az ACME fiók regisztrálva lett az ACME kiszolgálón
hiba a "acme-tls" Secret megtalálásakor: Secrets "acme-tls" nem található
Nem Előtt: 
Nem Után: 
Megújítási idő: 
CertificateRequest:
  Név: acme-certificate-qp5dm
  Namespace: default
  Állapotok:
    Készen: False, Ok: Pending, Üzenet: Várakozás a tanúsítvány kiadására a default/acme-certificate-qp5dm-1319513028 rendelésből: "pending"
  Események:
    Típus    Ok        Kor   Ki            Üzenet
    ----    ------        ----  ----          -------
    Normális  RendelésLétrehozva  18m   cert-manager  Rendelés forrás létrehozása default/acme-certificate-qp5dm-1319513028
Rendelés:
  Név: acme-certificate-qp5dm-1319513028
  Állapot: pending, Ok:
  Engedélyezések:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Azonosító: example.com, Kezdeti állapot: pending, Wildcard: false
Kihívások:
- Név: acme-certificate-qp5dm-1319513028-1825664779, Típus: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Kulcs: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Állapot: pending, Ok: hiba a clouddns szolgáltatás fiókjának megszerzésében: secret "clouddns-accoun" nem található, Feldolgozás: true, Bemutatva: false

A parancs szintén segíthet többet megtudni a tanúsítvány tartalmáról. Példa a Letsencrypt által kiadott tanúsítvány részleteiről:

$ kubectl cert-manager status certificate example
Név: example
[...]
Secret:
  Név: example
  Kibocsátó Ország: US
  Kibocsátó Szervezet: Let's Encrypt
  Kibocsátó Közönséges Név: Let's Encrypt Authority X3
  Kulcs Használat: Digitális Aláírás, Kulcs Titkosítás
  Kiterjesztett Kulcs Használatok: Kiszolgáló Hitelesítés, Ügyfél Hitelesítés
  Nyilvános Kulcs Algoritmus: RSA
  Aláírási Algoritmus: SHA256-RSA
  Tárgy Kulcs Azonosító: 65081d98a9870764590829b88c53240571997862
  Hatósági Kulcs Azonosító: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Sorozatszám: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Események:  
Nem Előtt: 2020-06-02T04:29:56+02:00
Nem Után: 2020-08-31T04:29:56+02:00
Megújítási idő: 2020-08-01T04:29:56+02:00
[...]

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

A cert-manager az egyik első volt, amely bevezette a Kubernetes CRD-ket. Ez, valamint a Kubernetes 1.11-ig terjedő verziók támogatása azt eredményezte, hogy a régi apiextensions.k8s.io/v1beta1 a CRD-khez, valamint admissionregistration.k8s.io/v1beta1 a webhookokhoz. Ezek most elavultak, és a Kubernetes 1.22-es verziójától törölni fogják. A 1.0-val most teljes támogatást nyújtunk apiextensions.k8s.io/v1 és admissionregistration.k8s.io/v1 a Kubernetes 1.16 számára (ahol ezek be lettek vezetve) és újabb verziókhoz. A korábbi verziók felhasználói számára továbbra is kínálunk támogatást v1beta1 a miénkben legacy verzióban.

Javított naplózás

Ebben a verzióban frissítettük a naplózási könyvtárat a következőre klog/v2, amelyet a Kubernetes 1.19 használ. Emellett minden naplót ellenőrzünk, amelyet írunk, hogy megfelelő szintet rendeljenek hozzá. Ebben az esetben a Kubernetes irányelveszolgáltatott irányt. Öt (valójában — hat, jegyzet: fordító) naplózási szint létezik, kezdve a Hiba (0. szint), amely csak fontos hibákat jelez, és az Trace (5. szint), amely segít pontosan megérteni, mi történik. Ezzel a változtatással csökkentettük a naplók számát, ha nem szükséges a hibakeresési információ a cert-manager működése közben.

Tipp: alapértelmezés szerint a cert-manager 2. szinten működik (Info), ezt felülbírálhatja a global.logLevel Helm chartban.

Megjegyzés: a naplók megtekintése az utolsó lehetőség a hibakeresés során. További információért tekintse meg a útmutatóval.

N.B. szerkesztő: A Kubernetes alatt működő folyamatok részletesebb megértéséhez, értékes tippek megszerzéséhez gyakorló tanítóktól, valamint minőségi támogatás megszerzéséhez csatlakozhat az online intenzív képzéseinkhez, Kubernetes Alapokamelyek szeptember 28-30. között, valamint Kubernetes Megaoktóber 14-16. között kerülnek megrendezésre.

ACME fejlesztések

A cert-manager leggyakoribb alkalmazása hivatkozások kibocsátásával kapcsolatos a Let’s Encrypt segítségével, ACME használatával. Az 1.0-ás verzió az közösség visszajelzéseit felhasználva két kisebb, de fontos fejlesztést tartalmaz az ACME kiadónkban.

Fiók kulcsának létrehozásának letiltása

Ha nagy mennyiségben használ ACME tanúsítványokat, valószínű, hogy ugyanazt a fiókot használja több klaszteren, így a tanúsítványok kibocsátására vonatkozó korlátok mindegyikre vonatkoznak. Ez már lehetséges volt a cert-manager-ben a titok másolásával, amely a privateKeySecretRefmegjegyzésre vonatkozik. Ez a felhasználási forma elég hibás volt, mivel a cert-manager megpróbált segíteni, és boldogan létrehozott egy új fiók kulcsot, ha azt nem találta. Ezért hozzáadtuk a disableAccountKeyGenerationbeállítást, hogy megvédjük Önt ettől a viselkedéstől, ha ezt a beállítást igaz — a cert-manager nem fog kulcsot létrehozni, és figyelmezteti Önt arra, hogy nem kapott fiók kulcsot.

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-én a Let’s Encrypt átmegy saját gyökérhitelesítő központjára ISRG Root. A keresztreferáló aláírású tanúsítványokat az Identrust. Ez a változás nem igényel módosítást a cert-manager beállításaiban, minden frissített vagy új tanúsítvány, amelyet e dátum után adnak ki, 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 ajánlja őket mint "alternatív tanúsítványláncot" az ACME-n keresztül. A cert-manager ezen verziójában lehetőség van megadni a hozzáférést ezekhez a láncokhoz az issuer beállításaiban. A preferredChain paraméterben megadhatja az aláírást végző CA nevét, amely segítségével a tanúsítványt kiadják. Ha elérhető a CA tanúsítvány, amely megfelel a kérésnek, kiadja Önnek a tanúsítványt. Kérjük, vegye figyelembe, hogy ez az előnyben részesített lehetőség, ha semmit nem talál – alapértelmezett tanúsítványt ad ki. Ez garantálja, hogy a tanúsítványát akkor is frissíti, miután eltávolították az alternatív láncot az ACME issuer oldalán.

Már ma is kérhet tanúsítványokat, amelyek ezt aláírják ISRG Root, az alábbiak szerint:

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 meg szeretné tartani a láncot IdenTrust – állítsa be ezt a paramétert 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"

Kérjük, vegye figyelembe, hogy ez a gyökérhitelesítő központ hamarosan elavulttá válik, a Let’s Encrypt ezt a láncot 2021. szeptember 29-ig aktívan támogatja.

Forrás: habr.com