Ruotare i certificati Kubernetes usando il motore del servizio Azure Kubernetes nell'hub di Azure Stack

  • Articolo

Questo documento fornisce indicazioni su come ruotare i certificati in un cluster del motore del servizio Azure Kubernetes esistente e consigli per l'uso dell'adozione aks-engine rotate-certs come strumento.

Prerequisiti

Questa guida presuppone che sia già stato distribuito un cluster usando il motore del servizio Azure Kubernetes e che il cluster si trovi in uno stato integro.

Pianificazione della rotazione dei certificati

Quando si valuta l'uso di questa funzionalità, tenere presente che il piano di controllo Kubernetes non sarà disponibile durante i passaggi di aggiornamento, convalida e riavvio. Pianificare l'operazione di manutenzione di conseguenza. Inoltre, pianificare l'esecuzione di questa operazione in un ambiente di staging con una configurazione uguale all'ambiente di produzione prima di provare in produzione.

Prima di tentare questa operazione, esaminare le considerazioni seguenti:

Nota

Per AKSe versione 0.75.3 e successive, i comandi per la rotazione dei certificati iniziano con aks-engine-azurestack anziché aks-engine.

  • Sarà necessario accedere al modello API (apimodel.json) generato dai comandi aks-engine deploy o aks-engine generate. Per impostazione predefinita, questo file viene inserito in una directory relativa, _output/<clustername>/ad esempio .

  • Un'operazione aks-engine rotate-certs causa tempi di inattività del server API.

  • aks-engine rotate-certs prevede un modello API conforme allo stato corrente del cluster. aks-engine rotate-certs esegue comandi remoti nei nodi del cluster e usa le informazioni sul modello API per stabilire una connessione SSH sicura. aks-engine rotate-certs si basa anche su alcune risorse da denominare in base alla distribuzione originale aks-engine , ad esempio, le macchine virtuali devono seguire la denominazione fornita da aks-engine.

  • aks-engine rotate-certs si basa su una connessione funzionante al piano di controllo del cluster durante la rotazione del certificato:

    • Per convalidare ogni passaggio del processo.
    • Per riavviare/ricreare risorse del cluster, ad esempio pod kube-system e token dell'account del servizio.

    Se si ruotano i certificati di un cluster in una rete virtuale chiusa all'accesso esterno, è necessario eseguire aks-engine rotate-certs da una macchina virtuale host con accesso di rete al piano di controllo, ad esempio una macchina virtuale jumpbox che si trova nella stessa rete virtuale delle macchine virtuali master.

  • Se si usa aks-engine rotate-certs nell'ambiente di produzione, è consigliabile preparare un test di rotazione dei certificati in un cluster creato in base alle stesse specifiche. Ovvero, il cluster viene compilato con la stessa configurazione del cluster, la stessa versione dello strumento da riga di comando del motore del servizio Azure Kubernetes e lo stesso set di componenti aggiuntivi abilitati del cluster di produzione prima di eseguire la rotazione del certificato. Il motore del servizio Azure Kubernetes supporta configurazioni cluster diverse e l'estensione dei test end-to-end eseguiti dal team del motore del servizio Azure Kubernetes non può coprire praticamente tutte le configurazioni possibili. È quindi consigliabile assicurarsi che in un ambiente di staging la configurazione del cluster specifica funzioni aks-engine rotate-certs prima di tentare l'operazione nel cluster di produzione.

  • aks-engine rotate-certsnon garantisce la compatibilità con le versioni precedenti. Se è stata distribuita con aks-engine versione 0.60.x, è consigliabile eseguire il processo di rotazione dei certificati con la versione 0.60.x.

  • Il recupero di un nuovo set di certificati da Key Vault non è supportato a questo punto.

  • Usare una connessione di rete affidabile. aks-engine rotate-certs richiede l'esecuzione di più comandi remoti, soggetti a potenziali errori, soprattutto se la connessione ai nodi del cluster non è affidabile. L'esecuzione aks-engine rotate-certs da una macchina virtuale in esecuzione nello stamp di Azure Stack di destinazione può ridurre l'occorrenza di problemi temporanei.

Parametri

Parametro Obbligatoria Descrizione
--api-model sì Percorso relativo del modello API (definizione del cluster) che dichiara la configurazione del cluster prevista.
--ssh-host sì Nome di dominio completo (FQDN) o indirizzo IP di un listener SSH in grado di raggiungere tutti i nodi del cluster.
--linux-ssh-private-key sì Percorso di una chiave SSH privata valida per accedere ai nodi Linux del cluster.
--location sì Percorso di Azure in cui viene distribuito il cluster.
--subscription-id sì Sottoscrizione di Azure in cui viene distribuita l'infrastruttura del cluster.
--resource-group sì Gruppo di risorse di Azure in cui viene distribuita l'infrastruttura del cluster.
--client-id Dipende ID client dell'entità servizio. Obbligatorio se il metodo di autenticazione è impostato su client_secret o client_certificate.
--client-secret Dipende Segreto client dell'entità servizio. Obbligatorio se il metodo di autenticazione è impostato su client_secret.
--azure-env Dipende Nome del cloud di destinazione. Facoltativo se il cloud di destinazione è AzureCloud.
--certificate-profile no Percorso relativo di un file JSON contenente il nuovo set di certificati.
--force no Forzare l'esecuzione anche se il server API non è reattivo.

Semplici passaggi per ruotare i certificati

Per il motore del servizio Azure Kubernetes versione 0.75.3 e successive, dopo aver letto tutti i requisiti, eseguire aks-engine-azurestack rotate-certs con gli argomenti appropriati (vedere di seguito).

Per il motore del servizio Azure Kubernetes versione 0.73.0 e successive, dopo aver letto tutti i requisiti, eseguire aks-engine rotate-certs con gli argomenti appropriati:

./bin/aks-engine rotate-certs \
  --location <resource-group-location> \
  --api-model <generated-apimodel.json> \
  --linux-ssh-private-key <private-SSH-key> \
  --ssh-host <apiserver-URI> \
  --resource-group <resource-group-name> \
  --client-id <service-principal-id> \
  --client-secret <service-principal-secret> \
  --subscription-id <subscription-id> \
  --azure-env <cloud-name>

Ad esempio:

./bin/aks-engine rotate-certs \
  --location "westus2" \
  --api-model "_output/my-cluster/apimodel.json" \
  --linux-ssh-private-key "~/.ssh/id_rsa" \
  --ssh-host "my-cluster.westus2.cloudapp.azure.com"\
  --resource-group "my-cluster" \
  --client-id "12345678-XXXX-YYYY-ZZZZ-1234567890ab" \
  --client-secret "12345678-XXXX-YYYY-ZZZZ-1234567890ab" \
  --subscription-id "12345678-XXXX-YYYY-ZZZZ-1234567890ab" \
  --azure-env "AzureStackCloud" # optional if targeting AzureCloud

Ruotare front-proxy i certificati

Nota

Per AKSe versione 0.75.3 e successive, i comandi per la rotazione dei certificati iniziano con aks-engine-azurestack anziché aks-engine.

Il motore del servizio Azure Kubernetes crea un'infrastruttura a chiave pubblica separata per come front-proxy parte del processo di bootstrap del nodo e li distribuisce a tutti i nodi tramite etcd. Per riutilizzare efficacemente questa funzionalità, rotate-certs è necessario sostituire i certificati archiviati in etcd. I front-proxy certificati scadono dopo 30 anni. aks-engine rotate-certs ruota i certificati front-proxy.

Risoluzione dei problemi

Nota

Per AKSe versione 0.75.3 e successive, i comandi per la rotazione dei certificati iniziano con aks-engine-azurestack anziché aks-engine.

Se il processo di rotazione del certificato viene interrotto prima del completamento a causa di un errore o di un problema temporaneo, ad esempio la connettività di rete, è possibile eseguire di nuovo aks-engine rotate-certs usando il --force flag .

Si noti anche che aks-engine rotate-certs registra l'output di ogni passaggio nel file /var/log/azure/rotate-certs.log (Linux) e c:\\k\\rotate-certs.log (Windows).

Per altre informazioni su cosa accade sotto le quinte durante l'esecuzione di questa operazione o per ulteriori personalizzazioni, vedere Under The Hood.

Passaggi successivi