🥇Cert-manager 1.0 è uscito

Se chiedi a un ingegnere esperto e saggio cosa pensa del cert-manager e perché tutti lo usano, allora lo specialista sospirerà, lo abbraccerà con fiducia e dirà stancamente: “Tutti lo usano, perché non ci sono alternative sensate. I nostri topi piangono, pungono, ma continuano a vivere con questo cactus. Perché amiamo? Perché funziona. Perché non amiamo? Perché escono costantemente nuove versioni che utilizzano nuove funzionalità. E devi aggiornare il cluster più e più volte. E le vecchie versioni smettono di funzionare, perché c'è una cospirazione e un grande misterioso sciamanesimo.

Ma gli sviluppatori lo affermano gestore di certificati 1.0 tutto cambierà.

Ci credi?

Cert-manager è il controller di gestione dei certificati Kubernetes nativo. Può essere utilizzato per emettere certificati da varie fonti: Let's Encrypt, HashiCorp Vault, Venafi, firma e coppie di chiavi autofirmate. Consente inoltre di mantenere aggiornate le chiavi in base alla data di scadenza e tenta inoltre di rinnovare automaticamente i certificati a un'ora specificata prima che scadano. Cert-manager è basato su kube-lego e ha utilizzato anche alcuni trucchi di altri progetti simili come kube-cert-manager.

Note di rilascio

Con la versione 1.0, diamo un marchio di fiducia per tre anni di sviluppo del progetto cert-manager. Durante questo periodo, si è evoluto in modo significativo in termini di funzionalità e stabilità, ma soprattutto nella comunità. Oggi vediamo molte persone che lo utilizzano per proteggere i propri cluster Kubernetes e per distribuirlo in varie parti dell'ecosistema. Molti bug sono stati corretti nelle ultime 16 versioni. E ciò che doveva essere rotto è rotto. Diverse visite per lavorare con l'API hanno migliorato la sua interazione con gli utenti. Abbiamo risolto 1500 problemi su GitHub con più richieste pull da 253 membri della community.

Con il rilascio della 1.0, dichiariamo ufficialmente che cert-manager è un progetto maturo. Promettiamo inoltre di mantenere la nostra API compatibile v1.

Mille grazie a tutti coloro che ci hanno aiutato a diventare cert-manager in tutti questi tre anni! Lascia che la versione 1.0 sia la prima di molte grandi cose a venire.

La versione 1.0 è una versione stabile con diverse aree prioritarie:

v1 FUOCO;
Squadra kubectl cert-manager status, per aiutare con l'analisi del problema;
Utilizzo delle ultime API Kubernetes stabili;
Registrazione migliorata;
Miglioramenti dell'ACME.

Assicurati di leggere le note di aggiornamento prima di eseguire l'aggiornamento.

API v1

La versione v0.16 funzionava con l'API v1beta1. Ciò ha aggiunto alcune modifiche strutturali e migliorato anche la documentazione del campo API. La versione 1.0 si basa su questo con un'API v1. Questa API è la nostra prima stabile, allo stesso tempo abbiamo già dato garanzie di compatibilità, ma con l'API v1 promettiamo di mantenere la compatibilità per gli anni a venire.

Modifiche apportate (nota: i nostri strumenti di conversione si occupano di tutto per te):

certificato:

emailSANs ora chiamato emailAddresses
uriSANs - uris

Queste modifiche aggiungono compatibilità con altre SAN (nomi alt soggetto, ca. traduttore), nonché con l'API Go. Stiamo rimuovendo questo termine dalla nostra API.

Aggiornare

Se utilizzi Kubernetes 1.16+, la conversione dei webhook ti consentirà di lavorare simultaneamente e senza problemi con le versioni dell'API v1alpha2, v1alpha3, v1beta1 и v1. Con questi, sarai in grado di utilizzare la nuova versione dell'API senza modificare o ridistribuire le tue vecchie risorse. Ti consigliamo vivamente di aggiornare i tuoi manifest all'API v1, poiché le versioni precedenti verranno presto ritirate. Utenti legacy le versioni di cert-manager avranno ancora accesso solo a v1, è possibile trovare i passaggi di aggiornamento qui.

comando kubectl cert-manager status

Con nuovi miglioramenti nella nostra estensione a kubectl è diventato più facile indagare sui problemi associati alla mancata emissione dei certificati. kubectl cert-manager status ora fornisce molte più informazioni su cosa sta succedendo con i certificati e mostra anche la fase di emissione del certificato.

Dopo aver installato l'estensione, puoi eseguire kubectl cert-manager status certificate <имя-сертификата>, che cercherà il certificato con il nome specificato e tutte le risorse correlate come CertificateRequest, Secret, Issuer e Order and Challenges se si utilizzano certificati di ACME.

Un esempio di debug di un certificato che non è ancora pronto:

$ 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

Il comando può anche aiutarti a saperne di più sul contenuto del certificato. Esempio dettagliato per un certificato emesso da 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
[...]

Utilizzando le ultime API Kubernetes stabili

Cert-manager è stato uno dei primi a implementare Kubernetes CRD. Questo, e il nostro supporto per le versioni di Kubernetes fino alla 1.11, significava che dovevamo supportare l'eredità apiextensions.k8s.io/v1beta1 anche per i nostri CRD admissionregistration.k8s.io/v1beta1 per i nostri webhook. Ora sono obsoleti e verranno rimossi in Kubernetes dalla versione 1.22. Con la nostra versione 1.0 ora offriamo un supporto completo apiextensions.k8s.io/v1 и admissionregistration.k8s.io/v1 per Kubernetes 1.16 (dove sono stati aggiunti) e successivi. Per gli utenti delle versioni precedenti, continuiamo a offrire supporto v1beta1 nel nostro legacy versione.

Registrazione migliorata

In questa versione, abbiamo aggiornato la libreria di registrazione a klog/v2, utilizzato in Kubernetes 1.19. Esaminiamo anche ogni rivista che scriviamo per assicurarci che sia assegnata al livello appropriato. Siamo stati guidati da questo guida da Kubernetes. Ce ne sono cinque (in realtà sei, ca. traduttore) livelli di registrazione a partire da Error (livello 0), che stampa solo gli errori importanti e termina con Trace (livello 5) che ti aiuterà a sapere esattamente cosa sta succedendo. Con questa modifica, abbiamo ridotto il numero di log se non hai bisogno di informazioni di debug durante l'esecuzione di cert-manager.

Suggerimento: cert-manager viene eseguito al livello 2 per impostazione predefinita (Info), puoi sovrascriverlo usando global.logLevel in Helmchart.

Nota: la visualizzazione dei registri è l'ultima risorsa durante la risoluzione dei problemi. Per maggiori informazioni consulta il nostro guida.

N.B. dell'editore: Per saperne di più su come funziona tutto sotto il cofano di Kubernetes, ottenere preziosi consigli dagli insegnanti praticanti, oltre a un supporto tecnico di qualità, puoi prendere parte a corsi intensivi online Base Kubernetes, che si terrà dal 28 al 30 settembre, e Kubernetes Megache si terrà dal 14 al 16 ottobre.

Miglioramenti dell'ACME

L'uso più comune di cert-manager è probabilmente correlato all'emissione di certificati da Let's Encrypt tramite ACME. La versione 1.0 si distingue per l'utilizzo del feedback della community per aggiungere due piccoli ma importanti miglioramenti al nostro emittente ACME.

Disabilita la generazione della chiave dell'account

Se utilizzi certificati ACME in grandi volumi, è probabile che utilizzi lo stesso account su più cluster, quindi le tue restrizioni sull'emissione di certificati si applicheranno a tutti. Questo era già possibile in cert-manager durante la copia del segreto specificato in privateKeySecretRef. Questo caso d'uso era piuttosto buggato, poiché cert-manager ha cercato di essere utile e ha creato felicemente una nuova chiave di account se non ne ha trovata una. Ecco perché abbiamo aggiunto disableAccountKeyGenerationper proteggerti da questo comportamento se imposti questa opzione su true - cert-manager non genererà una chiave e ti avviserà che non è stata fornita una chiave dell'account.

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

Catena preferita

29 settembre Criptiamo andrà oltre alla tua CA principale ISRG Root. I certificati con firma incrociata saranno sostituiti da Identrust. Questa modifica non richiede modifiche alle impostazioni di cert-manager, tutti i certificati aggiornati o nuovi emessi dopo questa data utilizzeranno la nuova CA radice.

Let's Encrypt firma già i certificati con questa CA e li offre come "catena di certificati alternativa" tramite ACME. In questa versione di cert-manager, è possibile impostare l'accesso a queste catene nelle impostazioni dell'emittente. Nel parametro preferredChain è possibile specificare il nome della CA in uso, con la quale verrà emesso il certificato. Se è disponibile un certificato CA corrispondente alla richiesta, verrà emesso un certificato. Si prega di notare che questa è l'opzione preferita, se non viene trovato nulla, verrà emesso un certificato predefinito. Ciò assicurerà che rinnoverai comunque il tuo certificato dopo aver eliminato la catena alternativa sul lato emittente ACME.

Già oggi puoi ricevere i certificati firmati da ISRG Root, Così:

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

Se preferisci lasciare la catena IdenTrust - impostare questa opzione su 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"

Tieni presente che questa CA radice verrà presto deprecata, Let's Encrypt manterrà questa catena attiva fino al 29 settembre 2021.

Fonte: habr.com

rilasciato cert-manager 1.0