Rotazione dei certificati nel servizio Azure Kubernetes

Il servizio Azure Kubernetes usa i certificati per l'autenticazione con molti dei rispettivi componenti. I cluster abilitati per il controllo degli accessi in base al ruolo creati dopo marzo 2022 sono abilitati con rotazione automatica dei certificati. È possibile che si debbano ruotare periodicamente tali certificati per motivi di sicurezza o criteri. Ad esempio, è possibile avere un criterio per ruotare tutti i certificati ogni 90 giorni.

Nota

La rotazione automatica dei certificati è abilitata solo per impostazione predefinita per i cluster del servizio Azure Kubernetes abilitati per il controllo degli accessi in base al ruolo.

Questo articolo illustra il funzionamento della rotazione dei certificati nel cluster del servizio Azure Kubernetes.

Operazioni preliminari

Questo articolo richiede l'interfaccia della riga di comando di Azure 2.0.77 o versione successiva. Eseguire az --version per trovare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure.

Certificati del servizio Azure Kubernetes, autorità di certificazione e account di servizio

Il servizio Azure Kubernetes genera e usa i certificati, le autorità di certificazione (CA) e gli account del servizio seguenti (SA):

  • Il server API del servizio Azure Kubernetes crea una CA denominata CA del cluster.
  • Il server API ha una CA del cluster, che firma i certificati per la comunicazione unidirezionale dal server API ai kubelet.
  • Ogni kubelet crea una richiesta di firma del certificato (CSR), firmata dalla CA del cluster, per la comunicazione dal kubelet al server API.
  • L'aggregatore API usa la CA del cluster per rilasciare certificati per la comunicazione con altre API. L'aggregatore API inoltre può avere la propria CA per il rilascio di tali certificati, ma attualmente usa la CA del cluster.
  • Ogni nodo usa un token Software Assurance, firmato dalla CA del cluster.
  • Il client kubectl ha un certificato per la comunicazione con il cluster del servizio Azure Kubernetes.

Microsoft gestisce tutti i certificati indicati in questa sezione, ad eccezione del certificato del cluster.

Nota

  • I cluster del servizio Azure Kubernetes creati prima di maggio 2019 hanno certificati che scadono dopo due anni.
  • I cluster del servizio Azure Kubernetes creati dopo maggio 2019 hanno certificati di CA cluster che scadono dopo 30 anni.

È possibile verificare quando il cluster è stato creato usando il comando kubectl get nodes, che mostra l'età dei pool di nodi.

Controllare le date di scadenza del certificato

Controllare la data di scadenza del certificato del cluster

  • Controllare la data di scadenza del certificato del cluster usando il comando kubectl config view.

    kubectl config view --raw -o jsonpath="{.clusters[?(@.name == '')].cluster.certificate-authority-data}" | base64 -d | openssl x509 -text | grep -A2 Validity
    

Controllare la data di scadenza del certificato del server API

  • Controllare la data di scadenza del certificato del server API usando il comando seguente curl.

    curl https://{apiserver-fqdn} -k -v 2>&1 | grep expire
    

Controllare la data di scadenza del certificato del nodo dell'agente VMAS

  • Controllare la data di scadenza del certificato del nodo dell’agente VMAS usando il comando az vm run-command invoke.

    az vm run-command invoke -g MC_rg_myAKSCluster_region -n vm-name --command-id RunShellScript --query 'value[0].message' -otsv --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate"
    

Controllare la data di scadenza del certificato del nodo del set di scalabilità di macchine virtuali

  • Controllare la data di scadenza del certificato del nodo dell’agente del set di scalabilità di macchine virtuali usando il comando az vm run-command invoke.

    az vmss run-command invoke --resource-group "MC_rg_myAKSCluster_region" --name "vmss-name" --command-id RunShellScript --instance-id 1 --scripts "openssl x509 -in /etc/kubernetes/certs/apiserver.crt -noout -enddate" --query "value[0].message"
    

Rotazione automatica dei certificati

Affinché il servizio Azure Kubernetes ruoti automaticamente i certificati non CA, il cluster deve avere Bootstrap TLS, che è abilitato per impostazione predefinita in tutte le aree di Azure.

Nota

  • Se si dispone di un cluster esistente, è necessario aggiornare tale cluster per abilitare la rotazione automatica dei certificati.
  • Non disabilitare Bootstrap per mantenere la rotazione automatica abilitata.
  • Se il cluster si trova in uno stato arrestato durante la rotazione automatica del certificato, vengono ruotati solo i certificati del piano di controllo. In questo caso, è necessario ricreare il pool di nodi dopo la rotazione del certificato per avviare la rotazione del certificato del pool di nodi.

Per tutti i cluster del servizio Azure Kubernetes creati o aggiornati dopo marzo 2022, il servizio Azure Kubernetes ruota automaticamente i certificati non CA nel piano di controllo e nei nodi agente entro l'80% del tempo valido del certificato client prima che scadano senza tempi di inattività per il cluster.

Come verificare se il pool di nodi dell'agente corrente è abilitato per il Bootstrap TLS?

  1. Verificare se il Bootstrap TLS del cluster è abilitato passando a uno dei percorsi seguenti:

    • In un nodo Linux: /var/lib/kubelet/bootstrap-kubeconfig o /host/var/lib/kubelet/bootstrap-kubeconfig
    • In un nodo Windows: C:\k\bootstrap-config

    Per altre informazioni, vedere Connettersi ai nodi del cluster del servizio Azure Kubernetes per la risoluzione dei problemi e le attività di manutenzione.

    Nota

    Il percorso del file può cambiare man mano che le versioni di Kubernetes si evolvono.

  2. Dopo aver configurato un'area, creare un nuovo cluster o aggiornare un cluster esistente per impostare la rotazione automatica per il certificato del cluster. È necessario aggiornare il piano di controllo e il pool di nodi per abilitare questa funzionalità.

Ruotare manualmente i certificati del cluster

Avviso

La rotazione dei certificati tramite az aks rotate-certs ricrea tutti i nodi, i set di scalabilità di macchine virtuali e i dischi e può causare fino a 30 minuti di inattività per il cluster del servizio Azure Kubernetes.

  1. Connettersi al cluster usando il comando az aks get-credentials.

    az aks get-credentials -g $RESOURCE_GROUP_NAME -n $CLUSTER_NAME
    
  2. Ruotare tutti i certificati, CA e autorità di certificazione nel cluster usando il comando az aks rotate-certs.

    az aks rotate-certs -g $RESOURCE_GROUP_NAME -n $CLUSTER_NAME
    

    Importante

    Il completamento di az aks rotate-certs può richiedere fino a 30 minuti. Se il comando ha esito negativo prima del completamento, usare az aks show per verificare che lo stato del cluster sia Rotazione del certificato. Se il cluster si trova in uno stato di errore, eseguire di nuovo az aks rotate-certs per ruotare nuovamente i certificati.

  3. Verificare che i certificati precedenti non siano più validi usando un comando kubectl qualsiasi, ad esempio kubectl get nodes.

    kubectl get nodes
    

    Se i certificati usati da kubectl non sono stati aggiornati, viene visualizzato un errore simile all'output di esempio seguente:

    Unable to connect to the server: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "ca")
    
  4. Aggiornare il certificato usato da kubectl con il comando az aks get-credentials con il flag --overwrite-existing.

    az aks get-credentials -g $RESOURCE_GROUP_NAME -n $CLUSTER_NAME --overwrite-existing
    
  5. Verificare che i certificati siano stati aggiornati usando il comando kubectl get.

    kubectl get nodes
    

    Nota

    Se si dispone di servizi eseguiti sul servizio Azure Kubernetes, potrebbe essere necessario aggiornare i certificati.

Passaggi successivi

Questo articolo ha illustrato come ruotare automaticamente i certificati del cluster, le CA e le autorità di certificazione. Per altre informazioni, vedere Procedure consigliate per la sicurezza e gli aggiornamenti dei cluster nel servizio Azure Kubernetes.