Plug in CA certificates for Istio-based service mesh add-on servizio Azure Kubernetes
Nell'addon della mesh di servizi basata su Istio per servizio Azure Kubernetes, per impostazione predefinita, l'autorità di certificazione Istio genera un certificato radice autofirmato e una chiave e li usa per firmare i certificati del carico di lavoro. Per proteggere la chiave CA radice, è necessario usare una CA radice eseguita offline in un computer protetto. È possibile usare la CA radice per rilasciare certificati intermedi alle CA Istio eseguite in ogni cluster. Una CA Istio può firmare i certificati del carico di lavoro usando il certificato e la chiave specificati dall'amministratore e distribuire un certificato radice specificato dall'amministratore ai carichi di lavoro come radice di attendibilità. Questo articolo illustra come usare certificati e chiavi personalizzati per la CA Istio nel componente aggiuntivo della mesh del servizio basato su Istio per il servizio Azure Kubernetes.
Questo articolo illustra come configurare l'autorità di certificazione Istio con un certificato radice, un certificato di firma e una chiave forniti come input usando Azure Key Vault per il componente aggiuntivo della mesh del servizio basato su Istio.
Operazioni preliminari
Verificare la versione dell'interfaccia della riga di comando di Azure
Il componente aggiuntivo richiede l'installazione dell'interfaccia della riga di comando di Azure versione 2.57.0 o successiva. È possibile eseguire az --version per verificare la versione. Per installare o aggiornare, vedere [Installare l'interfaccia della riga di comando di Azure][azure-cli-install].
Configurare Azure Key Vault
È necessaria una risorsa di Azure Key Vault per fornire il certificato e gli input della chiave al componente aggiuntivo Istio.
È necessario generare il certificato radice, i certificati intermedi, la chiave intermedia e la catena di certificati offline. I passaggi da 1 a 3 qui mostrano un esempio di come generare questi file.
Creare segreti in Azure Key Vault usando i certificati e la chiave:
az keyvault secret set --vault-name $AKV_NAME --name root-cert --file <path-to-folder/root-cert.pem> az keyvault secret set --vault-name $AKV_NAME --name ca-cert --file <path-to-folder/ca-cert.pem> az keyvault secret set --vault-name $AKV_NAME --name ca-key --file <path-to-folder/ca-key.pem> az keyvault secret set --vault-name $AKV_NAME --name cert-chain --file <path/cert-chain.pem>Abilitare il provider di Azure Key Vault per il driver CSI dell'archivio segreto per un cluster:
az aks enable-addons --addons azure-keyvault-secrets-provider --resource-group $RESOURCE_GROUP --name $CLUSTERNota
Quando si ruotano certificati, è possibile usare il parametro
--rotation-poll-intervaldel componente aggiuntivo provider di segreti di Azure Key Vault per controllare la velocità con cui i segreti vengono sincronizzati con il cluster. Ad esempio:az aks addon update --resource-group $RESOURCE_GROUP --name $CLUSTER --addon azure-keyvault-secrets-provider --enable-secret-rotation --rotation-poll-interval 20sAutorizzare l'identità gestita assegnata dall'utente del componente aggiuntivo per avere accesso alla risorsa di Azure Key Vault:
OBJECT_ID=$(az aks show --resource-group $RESOURCE_GROUP --name $CLUSTER --query 'addonProfiles.azureKeyvaultSecretsProvider.identity.objectId' -o tsv) az keyvault set-policy --name $AKV_NAME --object-id $OBJECT_ID --secret-permissions get listNota
Se l'insieme di credenziali delle chiavi è stato creato con l'autorizzazione del controllo degli accessi in base al ruolo di Azure per il modello di autorizzazione anziché criteri di accesso all'insieme di credenziali, seguire le istruzioni riportate qui per creare le autorizzazioni per l'identità gestita. Aggiungere un'assegnazione di ruolo di Azure per
Key Vault Readerl'identità gestita assegnata dall'utente del componente aggiuntivo.
Configurare il componente aggiuntivo della mesh del servizio basato su Istio con certificati CA plug-in
Abilitare il componente aggiuntivo della mesh del servizio Istio per un cluster del servizio Azure Kubernetes esistente facendo riferimento ai segreti di Azure Key Vault creati in precedenza:
az aks mesh enable --resource-group $RESOURCE_GROUP --name $CLUSTER \ --root-cert-object-name root-cert \ --ca-cert-object-name ca-cert \ --ca-key-object-name ca-key \ --cert-chain-object-name cert-chain \ --key-vault-id /subscriptions/$SUBSCRIPTION/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.KeyVault/vaults/$AKV_NAMENota
Per cluster esistenti con componente aggiuntivo Istio che usano il certificato radice autofirmato generato dalla CA Istio, il passaggio alla CA plug-in non è supportato. Prima di tutto, disabilitare la mesh nei cluster, quindi abilitarla di nuovo usando il comando precedente per bypassare gli input CA del plug-in.
Verificare che l'oggetto
cacertsvenga creato nel cluster:kubectl get secret -n aks-istio-systemOutput previsto:
NAME TYPE DATA AGE cacerts opaque 4 13h sh.helm.release.v1.azure-service-mesh-istio-discovery.v380 helm.sh/release.v1 1 2m15s sh.helm.release.v1.azure-service-mesh-istio-discovery.v381 helm.sh/release.v1 1 8sVerificare che il piano di controllo Istio abbia acquisito l'autorità di certificazione personalizzata:
kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system | grep -v validationController | grep x509L'output dovrebbe essere simile al seguente:
2023-11-06T15:49:15.493732Z info x509 cert - Issuer: "CN=Intermediate CA - A1,O=Istio,L=cluster-A1", Subject: "", SN: e191d220af347c7e164ec418d75ed19e, NotBefore: "2023-11-06T15:47:15Z", NotAfter: "2033-11-03T15:49:15Z" 2023-11-06T15:49:15.493764Z info x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Intermediate CA - A1,O=Istio,L=cluster-A1", SN: 885034cba2894f61036f2956fd9d0ed337dc636, NotBefore: "2023-11-04T01:40:02Z", NotAfter: "2033-11-01T01:40:02Z" 2023-11-06T15:49:15.493795Z info x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Root A,O=Istio", SN: 18e2ee4089c5a7363ec306627d21d9bb212bed3e, NotBefore: "2023-11-04T01:38:27Z", NotAfter: "2033-11-01T01:38:27Z"
Rotazione dell'autorità di certificazione
Potrebbe essere necessario ruotare le autorità di certificazione periodicamente per motivi di sicurezza o norme. Questa sezione illustra come gestire scenari intermedi di rotazione CA e CA radice.
Rotazione intermedia dell'autorità di certificazione
È possibile ruotare la CA intermedia mantenendo invariata la CA radice. Aggiornare i segreti nella risorsa di Azure Key Vault ai nuovi file di certificato e chiave:
az keyvault secret set --vault-name $AKV_NAME --name root-cert --file <path-to-folder/root-cert.pem> az keyvault secret set --vault-name $AKV_NAME --name ca-cert --file <path-to-folder/ca-cert.pem> az keyvault secret set --vault-name $AKV_NAME --name ca-key --file <path-to-folder/ca-key.pem> az keyvault secret set --vault-name $AKV_NAME --name cert-chain --file <path/cert-chain.pem>Attendere per la durata di
--rotation-poll-interval. Controllare se il segretocacertsè stato aggiornato nel cluster in base alla nuova CA intermedia aggiornata nella risorsa di Azure Key Vault:kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system | grep -v validationControllerL'output dovrebbe essere simile al seguente:
2023-11-07T06:16:21.091844Z info Update Istiod cacerts 2023-11-07T06:16:21.091901Z info Using istiod file format for signing ca files 2023-11-07T06:16:21.354423Z info Istiod has detected the newly added intermediate CA and updated its key and certs accordingly 2023-11-07T06:16:21.354910Z info x509 cert - Issuer: "CN=Intermediate CA - A2,O=Istio,L=cluster-A2", Subject: "", SN: b2753c6a23b54d8364e780bf664672ce, NotBefore: "2023-11-07T06:14:21Z", NotAfter: "2033-11-04T06:16:21Z" 2023-11-07T06:16:21.354967Z info x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Intermediate CA - A2,O=Istio,L=cluster-A2", SN: 17f36ace6496ac2df88e15878610a0725bcf8ae9, NotBefore: "2023-11-04T01:40:22Z", NotAfter: "2033-11-01T01:40:22Z" 2023-11-07T06:16:21.355007Z info x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Root A,O=Istio", SN: 18e2ee4089c5a7363ec306627d21d9bb212bed3e, NotBefore: "2023-11-04T01:38:27Z", NotAfter: "2033-11-01T01:38:27Z" 2023-11-07T06:16:21.355012Z info Istiod certificates are reloadedI carichi di lavoro ricevono certificati dal piano di controllo Istio validi per 24 ore per impostazione predefinita. Se i pod non vengono riavviati, tutti i carichi di lavoro ottengono nuovi certificati foglia in base alla nuova CA intermedia entro 24 ore. Se si vuole forzare tutti i carichi di lavoro a ottenere immediatamente nuovi certificati foglia dalla nuova CA intermedia, è necessario riavviare i carichi di lavoro.
kubectl rollout restart deployment <deployment name> -n <deployment namespace>
Rotazione dell'autorità di certificazione radice
È necessario aggiornare i segreti di Azure Key Vault tramite il file del certificato radice con la concatenazione dei certificati radice precedenti e quelli nuovi:
az keyvault secret set --vault-name $AKV_NAME --name root-cert --file <path-to-folder/root-cert.pem> az keyvault secret set --vault-name $AKV_NAME --name ca-cert --file <path-to-folder/ca-cert.pem> az keyvault secret set --vault-name $AKV_NAME --name ca-key --file <path-to-folder/ca-key.pem> az keyvault secret set --vault-name $AKV_NAME --name cert-chain --file <path/cert-chain.pem>Il contenuto di
root-cert.pemsegue questo formato:-----BEGIN CERTIFICATE----- <contents of old root certificate> -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- <contents of new root certificate> -----END CERTIFICATE-----Il componente aggiuntivo esegue
CronJobnel cluster ogni dieci minuti per verificare la disponibilità di aggiornamenti del certificato radice. Se un aggiornamento è rilevato, il piano di controllo Istio (distribuzioneistiod) viene riavviato per acquisire gli aggiornamenti. Controllare i log per verificare che l'aggiornamento del certificato radice sia stato rilevato e che il piano di controllo Istio sia stato riavviato:kubectl logs -n aks-istio-system $(kubectl get pods -n aks-istio-system | grep 'istio-cert-validator-cronjob-' | sort -k8 | tail -n 1 | awk '{print $1}')Output previsto:
Root certificate update detected. Restarting deployment... deployment.apps/istiod-asm-1-17 restarted Deployment istiod-asm-1-17 restarted.Dopo che
istiodè stato riavviato, dovrebbe indicare l’aggiunta di due certificati al dominio di attendibilità:kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-systemOutput previsto:
2023-11-07T06:42:00.287916Z info Using istiod file format for signing ca files 2023-11-07T06:42:00.287928Z info Use plugged-in cert at etc/cacerts/ca-key.pem 2023-11-07T06:42:00.288254Z info x509 cert - Issuer: "CN=Intermediate CA - A2,O=Istio,L=cluster-A2", Subject: "", SN: 286451ca8ff7bf9e6696f56bef829d42, NotBefore: "2023-11-07T06:40:00Z", NotAfter: "2033-11-04T06:42:00Z" 2023-11-07T06:42:00.288279Z info x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Intermediate CA - A2,O=Istio,L=cluster-A2", SN: 17f36ace6496ac2df88e15878610a0725bcf8ae9, NotBefore: "2023-11-04T01:40:22Z", NotAfter: "2033-11-01T01:40:22Z" 2023-11-07T06:42:00.288298Z info x509 cert - Issuer: "CN=Root A,O=Istio", Subject: "CN=Root A,O=Istio", SN: 18e2ee4089c5a7363ec306627d21d9bb212bed3e, NotBefore: "2023-11-04T01:38:27Z", NotAfter: "2033-11-01T01:38:27Z" 2023-11-07T06:42:00.288303Z info Istiod certificates are reloaded 2023-11-07T06:42:00.288365Z info spiffe Added 2 certs to trust domain cluster.local in peer cert verifierAttendere 24 ore (il tempo predefinito per la validità del certificato foglia) o forzare un riavvio di tutti i carichi di lavoro. In questo modo, tutti i carichi di lavoro riconoscono sia le autorità di certificazione precedenti che le nuove autorità di certificazione per la verifica mTLS.
kubectl rollout restart deployment <deployment name> -n <deployment namespace>È ora possibile aggiornare i segreti di Azure Key Vault usando solo la nuova CA (senza quella precedente):
az keyvault secret set --vault-name $AKV_NAME --name root-cert --file <path-to-folder/root-cert.pem> az keyvault secret set --vault-name $AKV_NAME --name ca-cert --file <path-to-folder/ca-cert.pem> az keyvault secret set --vault-name $AKV_NAME --name ca-key --file <path-to-folder/ca-key.pem> az keyvault secret set --vault-name $AKV_NAME --name cert-chain --file <path/cert-chain.pem>Controllare i log di
CronJobper confermare il rilevamento dell'aggiornamento del certificato radice e il riavvio diistiod:kubectl logs -n aks-istio-system $(kubectl get pods -n aks-istio-system | grep 'istio-cert-validator-cronjob-' | sort -k8 | tail -n 1 | awk '{print $1}')Output previsto:
Root certificate update detected. Restarting deployment... deployment.apps/istiod-asm-1-17 restarted Deployment istiod-asm-1-17 restarted.Dopo che
istiodè stato aggiornato, dovrebbe confermare solo l'utilizzo della nuova CA radice:kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system | grep -v validationControllerOutput previsto:
2023-11-07T08:01:17.780299Z info x509 cert - Issuer: "CN=Intermediate CA - B1,O=Istio,L=cluster-B1", Subject: "", SN: 1159747c72cc7ac7a54880cd49b8df0a, NotBefore: "2023-11-07T07:59:17Z", NotAfter: "2033-11-04T08:01:17Z" 2023-11-07T08:01:17.780330Z info x509 cert - Issuer: "CN=Root B,O=Istio", Subject: "CN=Intermediate CA - B1,O=Istio,L=cluster-B1", SN: 2aba0c438652a1f9beae4249457023013948c7e2, NotBefore: "2023-11-04T01:42:12Z", NotAfter: "2033-11-01T01:42:12Z" 2023-11-07T08:01:17.780345Z info x509 cert - Issuer: "CN=Root B,O=Istio", Subject: "CN=Root B,O=Istio", SN: 3f9da6ddc4cb03749c3f43243a4b701ce5eb4e96, NotBefore: "2023-11-04T01:41:54Z", NotAfter: "2033-11-01T01:41:54Z"Dagli esempi di output mostrati in questo articolo è possibile osservare che ci si è spostati dalla radice A (usata quando si abilita il componente aggiuntivo) alla radice B.
Attendere di nuovo 24 ore o forzare il riavvio di tutti i carichi di lavoro. Forzando un riavvio, i carichi di lavoro ottengono immediatamente nuovi certificati foglia dalla nuova CA radice.
kubectl rollout restart deployment <deployment name> -n <deployment namespace>