Condividi tramite


Collegare i certificati della CA per il componente aggiuntivo della mesh del servizio basato su Istio nel servizio Azure Kubernetes

Nel componente aggiuntivo della mesh del servizio basato su Istio per il 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.

Diagramma che mostra la CA radice e quella intermedia con Istio.

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 la versione dell'interfaccia della riga di comando di Azure 2.57.0 o versione 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

  1. È necessaria una risorsa di Azure Key Vault per fornire il certificato e gli input della chiave al componente aggiuntivo Istio.

  2. È 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.

  3. 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-to-folder/cert-chain.pem>
    
  4. 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 $CLUSTER
    

    Nota

    Quando si ruotano certificati, è possibile usare il parametro --rotation-poll-interval del 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 20s

  5. Autorizzare 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 list
    

    Nota

    Se si è creato l'insieme di credenziali delle chiavi con l'autorizzazione del controllo degli accessi in base al ruolo di Azure per il modello di autorizzazione anziché il criterio di accesso all’insieme di credenziali, seguire le istruzioni riportate qui relative alla creazione delle autorizzazioni per l'identità gestita. Aggiungere un'assegnazione di ruolo di Azure per Key Vault Reader a favore dell'identità gestita assegnata dall'utente del componente aggiuntivo.

Configurare il componente aggiuntivo della mesh del servizio basato su Istio con certificati CA plug-in

  1. 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_NAME
    

    Nota

    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.

  2. Verificare che l'oggetto cacerts venga creato nel cluster:

    kubectl get secret -n aks-istio-system
    

    Output 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      8s    
    
  3. Verificare 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 x509
    

    L'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

  1. È 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>
    
  2. Attendere per la durata di --rotation-poll-interval. Controllare se il segreto cacerts è 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 validationController
    

    L'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 reloaded
    
  3. I 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

  1. È 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.pem segue questo formato:

    -----BEGIN CERTIFICATE-----
    <contents of old root certificate>
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    <contents of new root certificate>
    -----END CERTIFICATE-----
    

    Il componente aggiuntivo esegue CronJob nel cluster ogni dieci minuti per verificare la disponibilità di aggiornamenti del certificato radice. Se un aggiornamento è rilevato, il piano di controllo Istio (distribuzione istiod) 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-system 
    

    Output 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 verifier
    
  2. Attendere 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>
    
  3. È 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 CronJob per confermare il rilevamento dell'aggiornamento del certificato radice e il riavvio di istiod:

    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 validationController
    

    Output 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.

  4. 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>