Distribuire cert-manager per Kubernetes con funzionalità Arc (anteprima)

Questo articolo illustra come distribuire l'estensione cert-manager per Kubernetes abilitata per Arc (anteprima) nei cluster connessi ad Arc. Sono inclusi i passaggi per una nuova distribuzione, insieme ai requisiti per la migrazione da un cluster con open source cert-manager e trust-manager.

Prerequisiti

Prima di installare CME, assicurarsi di soddisfare i prerequisiti seguenti:

• Un account Azure. Se non ne hai uno, crea un account gratuito prima di iniziare.

• Un cluster Kubernetes abilitato per Arc distribuito in un'area supportata. Per ottenere risultati ottimali, utilizzate una distribuzione Kubernetes convalidata per l'uso con cert-manager per Arc-enabled Kubernetes. Se il cluster non è già stato connesso ad Azure Arc, segui la nostra guida rapida. Prendere nota del nome del cluster e del gruppo di risorse Azure, perché saranno necessari per installare l'estensione.

• Amministratore delle risorse del computer connesso di Azure o un ruolo equivalente nella risorsa del cluster che consente di implementare le estensioni.

• Versione più recente di Azure CLI.

• La versione più recente delle estensioni connectedk8s e k8s-extension Azure CLI. Eseguire questi comandi per installare o aggiornare le estensioni:

  az extension add --upgrade -n connectedk8s
  az extension add --upgrade -n k8s-extension
  

• Versione installata di kubectl per il cluster (privilegi di amministratore). Sebbene non sia strettamente necessario per installare l'estensione, kubectl è utile per verificare l'installazione e gestire le risorse personalizzate del certificato nei passaggi successivi.

• Se in precedenza è stato installato open source cert-manager o trust-manager manualmente, disinstallarli prima di distribuire l'estensione Arc per evitare conflitti. Le risorse personalizzate esistenti (CR) verranno mantenute e riconosciute dall'estensione, purché rispettino le convenzioni dei progetti open source. Per ulteriori informazioni, consultare Migrare da cert-manager e trust-manager open source.

Le informazioni generali su Kubernetes abilitato per Arc, cert-manager e trust-manager possono essere utili, ma non sono necessarie per distribuire l'estensione.

Distribuire cert-manager per Kubernetes abilitato per Arc

Per distribuire cert-manager per Kubernetes abilitato per Arc (anteprima) in un cluster che non dispone già di cert-manager e trust-manager e che soddisfa i prerequisiti, usare il comando seguente:

az k8s-extension create \
  --resource-group ${RESOURCE_GROUP} \
  --cluster-name ${CLUSTER_NAME} \
  --cluster-type connectedClusters \
  --name "azure-cert-management" \
  --extension-type "microsoft.certmanagement" \

È possibile aggiungere --auto-upgrade-minor-version true per ricevere automaticamente gli aggiornamenti della versione secondaria, che includono nuove funzionalità e modifiche non di rilievo. In caso contrario, è possibile aggiornare manualmente l'estensione quando necessario per ottenere le funzionalità e le correzioni più recenti.

Dopo che il Azure CLI conferma che l'installazione è riuscita, verificare che i componenti siano in esecuzione nel cluster.

Ambienti PSA con restrizioni

Cert-manager per Kubernetes abilitato ad Azure Arc richiede l'accesso privilegiato per la raccolta dei log nell'ambiente Azure, al fine di fornire supporto e risolvere problemi. Per gli ambienti con restrizioni Pod Security Standards (PSA) in cui l'accesso con privilegi non è consentito, è possibile disabilitare la raccolta di log in Azure per rispettare i requisiti di sicurezza.

Per disabilitare la raccolta di log, usare --set global.telemetry.logs.enabled=false. Questo impedisce l'impostazione dei volumi di log e rimuove la necessità di accesso con privilegi, mentre la raccolta delle metriche continua normalmente.

Per disabilitare la raccolta di metriche, usare --set global.telemetry.metrics.enabled=false.

Eseguire la migrazione da open source cert-manager e trust-manager

L'estensione cert-manager per Kubernetes abilitata per Azure Arc funge da sostituzione per open source cert-manager e trust-manager. Prima di installare cert-manager per Kubernetes con compatibilità Arc, è necessario prima disinstallare le risorse open source.

I passaggi specifici per la disinstallazione dipendono dal metodo di installazione. Per istruzioni, vedere la documentazione per la disinstallazione di cert-manager e la disinstallazione di trust-manager. Se è stato usato Helm per l'installazione, usare questo comando per verificare in quale namespace sono installati cert-manager e trust-manager:

helm list -A | grep -E 'trust-manager|cert-manager'

Successivamente, usare i comandi seguenti per disinstallare:

helm uninstall cert-manager -n "your namespace" --ignore-not-found
helm uninstall trust-manager -n "your namespace" --ignore-not-found

Configurare cert-manager per Kubernetes abilitato per Arc

Dopo aver distribuito l'estensione cert-manager per Kubernetes abilitata per Arc, configurare la modalità di rilascio dei certificati, quindi richiedere un certificato per un carico di lavoro. In genere, i passaggi sono:

1. Creare una risorsa Issuer o ClusterIssuer per specificare un'Autorità di Certificazione (CA) che genererà certificati firmati. Può trattarsi di un'autorità di certificazione autofirmata (CA), un account registrato con un server dell'autorità di certificazione ACME (Automated Certificate Management Environment), ad esempio Let's Encrypt (o altri) o un'autorità di certificazione il cui certificato e la chiave privata sono archiviati all'interno del cluster come segreto Kubernetes.
2. Creare una risorsa Certificato che richiede una richiesta di certificato TLS e include i campi usati per generare richieste di firma del certificato (CSR), che vengono quindi soddisfatte dal tipo di autorità emittente a cui viene fatto riferimento sulla risorsa per un dominio o un uso specifico.
3. Consentire a cert-manager di soddisfare la richiesta, che comporta l'archiviazione di un certificato firmato e una chiave privata in un segreto Kubernetes che l'applicazione può usare.
4. Facoltativamente, se lo scenario richiede radici di attendibilità personalizzate tra gli spazi dei nomi, usare trust-manager per distribuire i certificati CA personalizzati a livello di cluster.

Le sezioni seguenti illustrano uno scenario di esempio per rilasciare un certificato autofirmato per un servizio in cluster.

Creare un ClusterIssuer autofirmato

Creare un ClusterIssuer (CA autofirmato)

Innanzitutto, configurare un clusterIssuer che usa un certificato autofirmato come CA. Questo ClusterIssuer fungerà da autorità di certificazione interna per il cluster, firmando i certificati per i carichi di lavoro. La CA deve essere supportata da chiavi private generate da RSA con una lunghezza minima di 4096.

Questo esempio usa un certificato autofirmato per illustrare il processo, adatto per la comunicazione o il test tra cluster, ma non è consigliato per i carichi di lavoro di produzione.

Applicare il manifesto YAML seguente per creare un ClusterIssuer autofirmato:

cat <<EOF | kubectl apply -f -
  apiVersion: cert-manager.io/v1
  kind: ClusterIssuer
  metadata:
    name: selfsigned-cluster-ca
  spec:
    selfSigned: {}
EOF

Questo definisce un ClusterIssuer denominato selfsigned-cluster-ca che rilascia certificati autofirmati (ovvero genera effettivamente un certificato radice CA per la firma). Dopo aver definito ClusterIssuer, cert-manager genera automaticamente una chiave radice e un certificato per l'emittente in background. Archivia il certificato CA generato e la chiave in un secret (per impostazione predefinita chiamato selfsigned-cluster-ca-cert nello stesso namespace di cert-manager, solitamente chiamato cert-manager)

Creare un certificato firmato da ClusterIssuer

A questo punto, richiedere un certificato per uno scopo specifico, ad esempio l'autenticazione del carico di lavoro. Creare una risorsa certificato che richiede un certificato per un nome interno come domain my-service.mydomainlocal, firmato dalla nuova CA del cluster auto-firmata.

cat <<EOF | kubectl apply -f -
  apiVersion: cert-manager.io/v1
  kind: Certificate
  metadata:
    name: my-service-cert
    namespace: default  # or the namespace where your application resides
  spec:
    secretName: my-service-tls 
    duration: 2160h            # 90 days (default) 
    renewBefore: 360h          # renew 15 days before expiration
    commonName: my-service.mydomain.local
    dnsNames:
    - my-service.mydomain.local
    issuerRef:
      name: selfsigned-cluster-ca     
      kind: ClusterIssuer
    privateKey:
      rotationPolicy: Always       
EOF

Questa specifica include i campi seguenti:

• secretName: my-service-tls è dove verrà archiviato il certificato e la chiave TLS risultanti (come segreto nello stesso spazio dei nomi). Le applicazioni useranno questo segreto.
• commonName e dnsNames specificano i nomi dei soggetti per il certificato. In questo esempio viene usato un nome DNS fittizio del servizio.
• issuerRef punta all'autorità emittente che è stata creata. Impostare kind: ClusterIssuer e name affinché faccia riferimento a ClusterIssuer CA autofirmato.

Entro pochi secondi, cert-manager genera una chiave privata e crea una richiesta CertificateSigningRequest all'autorità emittente di riferimento. Poiché questa autorità emittente è autofirmata, cert-manager fungerà da firmatario usando la chiave CA generata in precedenza.

Distribuire il pacchetto di fiducia (facoltativo)

Se si utilizzano solo certificati autofirmati all'interno del cluster, potrebbe essere desiderabile che tutti i carichi di lavoro considerino attendibile la CA radice autofirmata del cluster in tutti gli spazi dei nomi. Trust Manager può distribuire la CA come ConfigMap, se necessario.

Creare una risorsa Certificate per archiviare la CA autofirmata nel segreto selfsigned-cluster-ca-cert:

cat <<EOF | kubectl apply -f -
  apiVersion: cert-manager.io/v1
  kind: Certificate
  metadata:
    name: selfsigned-cluster-ca-cert
    namespace: cert-manager
  spec:
    isCA: true
    commonName: selfsigned-cluster-ca-cert
    secretName: selfsigned-cluster-ca-cert
    privateKey:
      algorithm: ECDSA
      size: 256
      rotationPolicy: Always      
    issuerRef:
      name: selfsigned-cluster-ca
      kind: ClusterIssuer
      group: cert-manager.io
EOF

Creare una risorsa Bundle per configurare il trust-manager in modo da distribuire il certificato CA.

cat <<EOF | kubectl apply -f -
  apiVersion: trust.cert-manager.io/v1alpha1
  kind: Bundle
  metadata:
    name: cluster-ca-bundle
    namespace: cert-manager
  spec:
    sources:
    - secret:
        name: selfsigned-cluster-ca-cert
        key: tls.crt
    target:
      configMap:
        key: ca.crt
EOF

Questa configurazione indica a trust-manager di accettare i dati del certificato dal segreto specificato (selfsigned-cluster-ca-cert) e di pubblicarli in un oggetto ConfigMap chiamato cluster-ca-bundle in tutti i namespace. La ConfigMap contiene una voce di dati ca.crt contenente il certificato della CA. Applicando questo bundle, trust-manager creerà e aggiornerà di conseguenza gli oggetti ConfigMap.

Tutti i pod possono quindi montare ConfigMap cluster-ca-bundle per considerare attendibile la CA personalizzata oppure è possibile fare riferimento a ConfigMap da altre estensioni. L'uso di un bundle di attendibilità è particolarmente utile se si usa una CA aziendale; Si distribuirà in modo analogo tale CA a tutti i pod che devono considerarlo attendibile.

In anteprima: Rimuovere cert-manager per Kubernetes con supporto Arc

Per disinstallare l'estensione cert-manager per Kubernetes abilitato per Arc (anteprima), usare il comando seguente:

az k8s-extension delete \
  --resource-group ${RESOURCE_GROUP} \
  --cluster-name ${CLUSTER_NAME} \
  --cluster-type connectedClusters \
  --name "azure-cert-management"

Questo comando rimuove le distribuzioni cert-manager e trust-manager. Non rimuove segreti e mappe di configurazione per i bundle di trust, ma rimuove i controller che li mantengono aggiornati. Tutti i certificati o gli emittenti creati rimarranno e tutti gli utenti di tali certificati potranno continuare a usarli fino alla scadenza. Per rimuovere completamente cert-manager dal cluster, rimuovere le risorse del certificato e dell'emittente che hai creato, e tutti i segreti generati.