Se chiedi a un ingegnere esperto e saggio cosa pensa di cert-manager e perché tutti lo usano, il tecnico sospirerà, ti abbraccerà affettuosamente e dirà stancamente: «Tutti lo usano perché non ci sono alternative valide. I nostri dolori piangono, si pungono, ma continuano a vivere con questo cactus. Perché ci piace? Perché funziona. Perché non ci piace? Perché escono costantemente nuove versioni che introducono nuove funzionalità. E dobbiamo aggiornare il cluster ripetutamente. Le vecchie versioni smettono di funzionare, perché c'è una cospirazione e un grande misterioso sciamanesimo».
Ma gli sviluppatori assicurano che con cert-manager 1.0 tutto cambierà.
Ci crederemo?
Cert-manager è il controllore nativo per la gestione dei certificati Kubernetes. Con esso è possibile emettere certificati da varie fonti: Let’s Encrypt, HashiCorp Vault, Venafi, coppie di chiavi per la firma e auto-firmati. Consente inoltre di mantenere le chiavi aggiornate in base alla validità e cerca di aggiornare automaticamente i certificati nel tempo stabilito 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. Nel corso di questo tempo, ha fatto notevoli progressi in funzionalità e stabilità, ma soprattutto nella comunità. Oggi vediamo molte persone utilizzarlo per proteggere i propri cluster Kubernetes e implementarlo in diverse parti dell'ecosistema. Negli ultimi 16 rilasci, è stato corretto un numero significativo di bug. E ciò che doveva essere rotto è stato rotto. Diverse modifiche all'API hanno migliorato l'interazione con gli utenti. Abbiamo risolto 1500 problemi su GitHub con un numero ancora maggiore di richieste di pull da 253 membri della comunità.
Con il rilascio della versione 1.0, dichiariamo ufficialmente che cert-manager è un progetto maturo. Promettiamo anche di mantenere la compatibilità della nostra API. v1.
Un enorme grazie a tutti coloro che ci hanno aiutato a rendere cert-manager ciò che è stato in questi tre anni! Che la versione 1.0 sia il primo di molti grandi traguardi futuri.
Il rilascio della versione 1.0 è una versione stabile con diverse aree prioritarie:
v1API;Team
kubectl cert-manager status, per aiutare nell'analisi dei problemi;Utilizzo delle API stabili più recenti di Kubernetes;
Migliore registrazione;
Miglioramenti per ACME.
Prima di aggiornare, leggi attentamente le note di rilascio.
API v1
La versione v0.16 funzionava con l'API v1beta1. Questo ha introdotto alcune modifiche strutturali e migliorato la documentazione sui campi dell'API. La versione 1.0 si basa su tutto ciò con l'API v1. Questa API è la nostra prima versione stabile, e nel frattempo abbiamo già fornito garanzie di compatibilità, ma con l'API v1 promettiamo di mantenere la compatibilità per anni a venire.
Modifiche apportate (nota: i nostri strumenti di conversione si prenderanno cura di tutto per te):
Certificato:
emailSANsora si chiamaemailAddressesuriSANs—uris
Queste modifiche aggiungono compatibilità con altri SAN (subject alt names, nota del traduttore), così come con Go API. Rimuoviamo questo termine dalla nostra API.
Aggiornamento
Se stai utilizzando Kubernetes 1.16+, i webhook di conversione ti consentiranno di lavorare contemporaneamente e senza soluzione di continuità con le versioni dell'API v1alpha2, v1alpha3, v1beta1 e v1. Con questi potrai utilizzare la nuova versione dell'API senza modificare o ridistribuire le tue vecchie risorse. Ti consigliamo vivamente di aggiornare i manifesti all'API v1, poiché le versioni precedenti saranno presto dichiarate obsolete. Gli utenti legacy della versione cert-manager avranno ancora accesso solo a v1, i passaggi per l'aggiornamento possono essere trovati .
Il comando kubectl cert-manager status
Con i nuovi miglioramenti nel nostro addon a kubectl è diventato più semplice esplorare i problemi legati al mancato rilascio dei certificati. kubectl cert-manager status ora fornisce molte più informazioni su ciò che sta accadendo con i certificati e mostra anche le fasi di emissione del certificato.
Dopo aver installato l'addon, puoi eseguire kubectl cert-manager status certificate, che comporterà la ricerca di un certificato con il nome specificato e di qualsiasi risorsa correlata, come CertificateRequest, Secret, Issuer, nonché Order e Challenges nel caso si utilizzino 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: False, Motivo: DoesNotExist, Messaggio: Emissione del certificato poiché il Secret non esiste
Emissione: True, Motivo: DoesNotExist, 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 Nuova chiave privata memorizzata nel Secret temporaneo "acme-certificate-tr8b2"
Normale Richiesto 18m cert-manager Creata nuova risorsa CertificateRequest "acme-certificate-qp5dm"
Emittente:
Nome: acme-issuer
Tipo: Emittente
Condizioni:
Pronto: True, Motivo: ACMEAccountRegistered, Messaggio: L'account ACME è stato registrato con il server ACME
errore nel trovare il Secret "acme-tls": secrets "acme-tls" non trovato
Non Prima:
Non Dopo:
Tempo di Rinnovo:
CertificateRequest:
Nome: acme-certificate-qp5dm
Namespace: default
Condizioni:
Pronto: False, Motivo: Pending, Messaggio: In attesa dell'emissione del certificato dall'ordine default/acme-certificate-qp5dm-1319513028: "pending"
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: pending, Motivo:
Autorizzazioni:
URL: https://acme-staging-v02.api.letsencrypt.org/acme/authz-v3/97777571, Identificatore: example.com, Stato Iniziale: pending, Wildcard: false
Sfide:
- Nome: acme-certificate-qp5dm-1319513028-1825664779, Tipo: DNS-01, Token: J-lOZ39yNDQLZTtP_ZyrYojDqjutMAJOxCL1AkOEZWw, Chiave: U_W3gGV2KWgIUonlO2me3rvvEOTrfTb-L5s0V1TJMCw, Stato: pending, Motivo: errore nel recuperare l'account di servizio clouddns: secret "clouddns-accoun" non trovato, Elaborazione: true, Presentato: false
Il team può anche aiutare a scoprire maggiori dettagli sul contenuto del certificato. Ecco un esempio di dettagli 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:
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
[...]
Utilizzo delle ultime API stabili di Kubernetes
Cert-manager è stato uno dei primi ad implementare le CRD di Kubernetes. Questo, insieme al nostro supporto per le versioni di Kubernetes fino alla 1.11, ha comportato la necessità di supportare la versione obsoleta apiextensions.k8s.io/v1beta1 per le nostre CRD, così come admissionregistration.k8s.io/v1beta1 per i nostri webhook. Attualmente, queste sono obsolete e verranno rimosse in Kubernetes a partire dalla versione 1.22. Con la nostra 1.0 offriamo ora il pieno supporto apiextensions.k8s.io/v1 e admissionregistration.k8s.io/v1 per Kubernetes 1.16 (dove sono state aggiunte) e versioni successive. Per gli utenti delle versioni precedenti continuiamo a offrire supporto v1beta1 nella nostra legacy versione.
Migliorato il logging
In questa versione abbiamo aggiornato la libreria per il logging a klog/v2, utilizzata in Kubernetes 1.19. Controlliamo anche ogni log che scriviamo per assegnargli il livello appropriato. Ci siamo basati su . Ci sono cinque (in realtà sei, nota del traduttore) livelli di logging, a partire 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, se non è necessaria l'informazione di debug durante l'uso del cert-manager.
Suggerimento: per impostazione predefinita, il cert-manager opera a livello 2 (Info), puoi sovrascriverlo utilizzando global.logLevel nel chart Helm.
Nota: la visualizzazione dei log è l'ultima risorsa nella risoluzione dei problemi. Per ulteriori informazioni, consulta il nostro .
N.B. editor: Per scoprire di più su come funziona tutto questo a livello interno in Kubernetes, ricevere preziosi suggerimenti da esperti pratici e anche un supporto tecnico di qualità, puoi partecipare agli intensivi online , che si svolgerà dal 28 al 30 settembre, e , che si terrà dal 14 al 16 ottobre.
Miglioramenti ACME
L'uso più comune di cert-manager è legato all'emissione di certificati da Let’s Encrypt utilizzando ACME. La versione 1.0 è notevole per l'uso di feedback dalla comunità per aggiungere due piccoli, ma importanti miglioramenti al nostro emittente ACME.
Disabilita la creazione della chiave dell'account
Se utilizzi certificati ACME su larga scala, probabilmente stai usando lo stesso account su più cluster, quindi i tuoi limiti di emissione dei certificati si applicheranno a tutti. Questo era già possibile in cert-manager copiando il segreto specificato in privateKeySecretRef. Questo 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 questo comportamento, se imposti questo parametro su true — cert-manager non creerà la chiave e ti avviserà che non è stata fornita la 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 al proprio centro di certificazione root ISRG Root. I certificati con firme incrociate verranno sostituiti da Identrust. Questa modifica non richiede modifiche nelle impostazioni di cert-manager; tutti i certificati aggiornati o nuovi emessi dopo questa data utilizzeranno il nuovo CA root.
Let’s Encrypt sta già firmando certificati con questo CA e li offre come "catena di certificati alternativa" tramite ACME. In questa versione di cert-manager è disponibile la possibilità di impostare l'accesso a queste catene nelle impostazioni dell'emittente. Nel parametro preferredChain puoi specificare il nome del CA utilizzato per emettere il certificato. Se sarà disponibile un certificato CA corrispondente alla richiesta, verrà emesso il certificato. Tieni presente che questa è l'opzione preferita; se nulla verrà trovato, verrà emesso un certificato di default. Questo garantirà che tu possa comunque aggiornare il tuo certificato dopo la rimozione della catena alternativa dal lato dell'emittente ACME.
Oggi è già possibile ricevere certificati firmati ISRG Root, come:
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"
Si prega di notare che questo centro di certificazione radice andrà in pensione a breve; Let’s Encrypt manterrà attiva questa catena fino al 29 settembre 2021.
Fonte: habr.com
