🥇È uscito cert-manager 1.0

Se si chiede a un esperto ingegnere esperto cosa pensa di cert-manager e perché tutti lo usano, il professionista sospirerà, abbraccerà fiducioso e dirà stancamente: «Tutti lo usano perché non ci sono alternative valide. I nostri topi piangono, si pungono, ma continuano a vivere con questo cactus. Perché lo amiamo? Perché funziona. Perché non lo amiamo? Perché escono continuamente nuove versioni che utilizzano nuove funzionalità. E dobbiamo riaggiornare il cluster di volta in volta. Le vecchie versioni smettono di funzionare, perché c'è una congiura e un grande e misterioso sciamanesimo».

Ma gli sviluppatori assicurano che cert-manager 1.0 cambierà tutto.

Ci possiamo credere?

Cert-manager è il controllore nativo per la gestione dei certificati Kubernetes. Con esso, è possibile emettere certificati da diverse fonti: Let’s Encrypt, HashiCorp Vault, Venafi, coppie di chiavi per la firma e auto-firmati. Consente anche di mantenere le chiavi aggiornate in termini di validità e cerca di aggiornare automaticamente i certificati in un momento prestabilito prima della loro scadenza. Cert-manager è basato su kube-lego e ha utilizzato alcune tecniche da altri progetti simili, come kube-cert-manager.

Note di rilascio

Con la versione 1.0, poniamo un segno di fiducia dopo tre anni di sviluppo del progetto cert-manager. Durante questo periodo, si è notevolmente evoluto in funzionalità e stabilità, ma soprattutto nella comunità. Oggi vediamo come molte persone lo utilizzano per proteggere i propri cluster Kubernetes e come sia impegnato in diverse parti dell'ecosistema. Negli ultimi 16 rilasci, sono stati corretti molti errori. E ciò che doveva essere rotto è stato rotto. Diversi tentativi di lavorare con l'API hanno migliorato la sua interazione con gli utenti. Abbiamo risolto 1500 problemi su GitHub con un numero ancora maggiore di richieste di fusione da 253 membri della comunità.

Pubblicando la 1.0, dichiariamo ufficialmente che cert-manager è un progetto maturo. Promettiamo anche di mantenere la compatibilità della nostra API v1.

Un enorme ringraziamento a tutti coloro che ci hanno aiutato a far crescere cert-manager in questi tre anni! Che la versione 1.0 sia il primo di molti grandi traguardi futuri.

Il rilascio 1.0 è una versione stabile con alcuni ambiti prioritari:

v1 API;
Team kubectl cert-manager status, per aiutare nell'analisi dei problemi;
Utilizzo delle ultime API stabili di Kubernetes;
Miglioramento della registrazione;
Miglioramenti ACME.

Prima di eseguire l'aggiornamento, assicurati di leggere le note di rilascio.

API v1

La versione v0.16 funzionava con l'API v1beta1. Ciò ha apportato alcune modifiche strutturali e migliorato la documentazione sui campi API. La versione 1.0 si basa su tutto questo grazie all'API v1. Questa API è la nostra prima stabile, e abbiamo già dato garanzie di compatibilità, ma con l'API v1 promettiamo di mantenere la compatibilità per gli anni a venire.

Le modifiche apportate (nota: i nostri strumenti di conversione si occuperanno di tutto per te):

Certificato:

emailSANs ora è chiamato emailAddresses
uriSANs — uris

Queste modifiche aggiungono compatibilità con altri SAN (subject alt names, nota del traduttore), così come con l'API di Go. Stiamo rimuovendo questo termine dalla nostra API.

Aggiornamento

Se utilizzi Kubernetes 1.16+ — i webhook di conversione ti permetteranno di lavorare contemporaneamente e senza soluzione di continuità con le versioni dell'API v1alpha2, v1alpha3, v1beta1 e v1. Con essi potrai utilizzare la nuova versione dell'API senza modificare o ridistribuire le tue vecchie risorse. Ti consigliamo di aggiornare i manifesti all'API v1, poiché le versioni precedenti verranno presto dichiarate obsolete. Gli utenti legacy della versione cert-manager avranno ancora accesso solo a v1, le istruzioni per l'aggiornamento possono essere trovate qui.

Il comando kubectl cert-manager status

Con i nuovi miglioramenti nella nostra estensione a kubectl è diventato più semplice esplorare problemi relativi alla non emissione dei certificati. kubectl cert-manager status ora fornisce molte più informazioni su cosa stia accadendo con i certificati e mostra anche le fasi di emissione del certificato.

Dopo aver installato l'estensione, puoi eseguire kubectl cert-manager status certificate, che porterà alla ricerca del certificato con il nome specificato e di eventuali risorse correlate come CertificateRequest, Secret, Issuer, e Order e Challenges nel caso tu stia utilizzando certificati da ACME.

Esempio di debug di un certificato non ancora pronto:

$ kubectl cert-manager status certificate acme-certificate

Nome: acme-certificate
Namespace: default
Creato il: 2020-08-21T16:44:13+02:00
Condizioni:
  Pronto: Falso, Motivo: NonEsiste, Messaggio: Emissione del certificato poiché il Secret non esiste
  Emissione: Vero, Motivo: NonEsiste, Messaggio: Emissione del certificato poiché il Secret non esiste
Nomi DNS:
- example.com
Eventi:
  Tipo    Motivo     Età   Da            Messaggio
  ----    ------     ----  ----          -------
  Normale  Emissione  18m   cert-manager  Emissione del certificato poiché il Secret non esiste
  Normale  Generato   18m   cert-manager  Memorizzato nuovo chiave privata in risorsa Secret temporanea "acme-certificate-tr8b2"
  Normale  Richiesto  18m   cert-manager  Creata nuova risorsa CertificateRequest "acme-certificate-qp5dm"
Emittente:
  Nome: acme-issuer
  Tipo: Emittente
  Condizioni:
    Pronto: Vero, Motivo: ACMEAccountRegistered, Messaggio: L'account ACME è stato registrato con il server ACME
errore durante la ricerca del Secret "acme-tls": secrets "acme-tls" non trovati
Non Prima: 
Non Dopo: 
Tempo di Rinnovo: 
CertificateRequest:
  Nome: acme-certificate-qp5dm
  Namespace: default
  Condizioni:
    Pronto: Falso, Motivo: InAttesa, Messaggio: In attesa dell'emissione del certificato dall'ordine default/acme-certificate-qp5dm-1319513028: "in attesa"
  Eventi:
    Tipo    Motivo        Età   Da            Messaggio
    ----    ------        ----  ----          -------
    Normale  OrdineCreato  18m   cert-manager  Creata risorsa Ordine default/acme-certificate-qp5dm-1319513028
Ordine:
  Nome: acme-certificate-qp5dm-1319513028
  Stato: in attesa, Motivo:
  Autorizzazioni:
    URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identificatore: example.com, Stato Iniziale: in attesa, Wildcard: falso
Sfide:
- Nome: acme-certificate-qp5dm-1319513028-1825664779, Tipo: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Chiave: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Stato: in attesa, Motivo: errore nel recuperare l'account di servizio clouddns: secret "clouddns-accoun" non trovato, Elaborazione: vero, Presentato: falso

Il comando può anche aiutare a scoprire ulteriori dettagli sul contenuto del certificato. Ecco un esempio di dettaglio per un certificato rilasciato da Letsencrypt:

$ kubectl cert-manager status certificate example
Nome: example
[...]
Secret:
  Nome: example
  Paese dell'emittente: US
  Organizzazione dell'emittente: Let's Encrypt
  Nome Comune dell'emittente: Let's Encrypt Authority X3
  Uso della Chiave: Firma Digitale, Cifratura della Chiave
  Usi Estesi della Chiave: Autenticazione del Server, Autenticazione del Client
  Algoritmo della Chiave Pubblica: RSA
  Algoritmo di Firma: SHA256-RSA
  ID Chiave del Soggetto: 65081d98a9870764590829b88c53240571997862
  ID Chiave dell'Autorità: a84a6a63047dddbae6d139b7a64565eff3a8eca1
  Numero di Serie: 0462ffaa887ea17797e0057ca81d7ba2a6fb
  Eventi:  
Non Prima: 2020-06-02T04:29:56+02:00
Non Dopo: 2020-08-31T04:29:56+02:00
Tempo di Rinnovo: 2020-08-01T04:29:56+02:00
[...]

Utilizzo delle ultime API stabili di Kubernetes

Cert-manager è stato uno dei primi a implementare i CRD di Kubernetes. Questo, insieme al nostro supporto per le versioni di Kubernetes fino alla 1.11, ha comportato la necessità di mantenere obsoleto apiextensions.k8s.io/v1beta1 per i nostri CRD, così come admissionregistration.k8s.io/v1beta1 per i nostri webhook. Adesso sono obsoleti e saranno rimossi in Kubernetes a partire dalla versione 1.22. Con la nostra 1.0 offriamo ora supporto completo apiextensions.k8s.io/v1 e admissionregistration.k8s.io/v1 per Kubernetes 1.16 (dove sono stati aggiunti) e versioni successive. Per gli utenti delle versioni precedenti, continuiamo a offrire supporto v1beta1 nella nostra legacy versione.

Registrazione avanzata

In questa versione abbiamo aggiornato la libreria per la registrazione a klog/v2, utilizzata in Kubernetes 1.19. Controlliamo anche ogni log che scriviamo per assegnargli il livello appropriato. Ci siamo basati su una guida di Kubernetes. Ci sono cinque (in realtà sei, nota del traduttore) livelli di registrazione, che vanno da Error (livello 0), che mostra solo errori critici, fino a Trace (livello 5), che aiuta a capire esattamente cosa sta succedendo. Con questa modifica abbiamo ridotto il numero di log, nel caso in cui non necessitiate di informazioni di debug durante l'utilizzo di cert-manager.

Consiglio: per impostazione predefinita, cert-manager opera a livello 2 (Info), puoi sovrascriverlo utilizzando global.logLevel nel chart di Helm.

Nota: visualizzare i log è l'ultima risorsa nella risoluzione dei problemi. Per ulteriori informazioni, consulta la nostra guida.

N.B. dell'editore: Per scoprire di più su come funziona tutto ciò sotto il cofano di Kubernetes, ricevere consigli preziosi da professionisti e ottenere un supporto tecnico di qualità, puoi partecipare ai corsi intensivi online Base Kubernetes, che si terrà dal 28 al 30 settembre, e Mega Kubernetes, che si terrà dal 14 al 16 ottobre.

Miglioramenti ACME

L'uso più comune di cert-manager è probabilmente legato all'emissione di certificati da Let’s Encrypt utilizzando ACME. La versione 1.0 è notevole per l'utilizzo di feedback della comunità per aggiungere due piccoli ma importanti miglioramenti al nostro emittente ACME.

Disattivazione della generazione della chiave dell'account

Se utilizzi certificati ACME in grandi volumi, molto probabilmente utilizzi lo stesso account su più cluster, quindi i tuoi limiti per l'emissione di certificati si applicano a tutti. Questo era già possibile in cert-manager copiando il segreto specificato in privateKeySecretRef. Questo caso d'uso era piuttosto problematico, poiché cert-manager cercava di essere utile e creava felicemente una nuova chiave dell'account se non la trovava. Pertanto, abbiamo aggiunto disableAccountKeyGeneration, per proteggerti da tale comportamento; impostando questo parametro su true — cert-manager non creerà una chiave e ti avviserà che non gli è 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 Let’s Encrypt passerà a un proprio centro di certificazione radice ISRG Root. I certificati con firme incrociate verranno sostituiti con Identrust. Questa modifica non richiede modifiche alle impostazioni del cert-manager; tutti i certificati aggiornati o nuovi emessi dopo questa data utilizzeranno il nuovo CA radice.

Let’s Encrypt sta già firmando certificati utilizzando questo CA e li offre come «catena di certificati alternativa» tramite ACME. In questa versione del cert-manager c'è la possibilità di specificare l'accesso a queste catene nelle impostazioni del 'issuer'. Nel parametro preferredChain puoi indicare il nome del CA utilizzato per emettere il certificato. Se sarà disponibile un certificato CA corrispondente alla richiesta, ti verrà rilasciato un certificato. Tieni presente che questa è l'opzione preferita; se non viene trovato nulla, verrà emesso un certificato predefinito. Ciò garantirà che tu comunque aggiorni il tuo certificato dopo la rimozione della catena alternativa dal lato del 'ACME issuer'.

Già oggi puoi ricevere certificati firmati 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 mantenere la catena IdenTrust — imposta questo parametro 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 questo centro di certificazione radice diventerà obsoleto a breve; Let’s Encrypt manterrà attiva questa catena fino al 29 settembre 2021.

Fonte: habr.com