Podłącz certyfikaty urzędu certyfikacji dla dodatku siatki usług opartej na istio w usłudze Azure Kubernetes Service

W dodatku siatki usługi opartej na architekturze Istio dla usługi Azure Kubernetes Service domyślnie urząd certyfikacji Istio generuje certyfikat główny z podpisem własnym i klucz i używa ich do podpisywania certyfikatów obciążenia. Aby chronić klucz głównego urzędu certyfikacji, należy użyć głównego urzędu certyfikacji, który działa na bezpiecznej maszynie w trybie offline. Za pomocą głównego urzędu certyfikacji można wystawiać certyfikaty pośrednie do urzędów certyfikacji Istio, które działają w każdym klastrze. Urząd certyfikacji Istio może podpisywać certyfikaty obciążenia przy użyciu certyfikatu i klucza określonego przez administratora oraz dystrybuować certyfikat główny określony przez administratora do obciążeń jako główny zaufania. W tym artykule opisano sposób dodawania własnych certyfikatów i kluczy dla urzędu certyfikacji Istio w dodatku siatki usługi opartej na technologii Istio dla usługi Azure Kubernetes Service.

Diagram przedstawiający główny i pośredni urząd certyfikacji z istio.

W tym artykule opisano sposób konfigurowania urzędu certyfikacji Istio przy użyciu certyfikatu głównego, certyfikatu podpisywania i klucza dostarczonego jako dane wejściowe przy użyciu usługi Azure Key Vault do dodatku siatki usług opartej na języku Istio.

Zanim rozpoczniesz

Weryfikowanie wersji interfejsu wiersza polecenia platformy Azure

Dodatek wymaga zainstalowania interfejsu wiersza polecenia platformy Azure w wersji 2.57.0 lub nowszej. Możesz uruchomić polecenie az --version , aby zweryfikować wersję. Aby zainstalować lub uaktualnić, zobacz [Instalowanie interfejsu wiersza polecenia platformy Azure][azure-cli-install].

Konfigurowanie usługi Azure Key Vault

  1. Potrzebny jest zasób usługi Azure Key Vault, aby podać dane wejściowe certyfikatu i klucza do dodatku Istio.

  2. Należy wygenerować certyfikat główny, certyfikaty pośrednie, klucz pośredni i łańcuch certyfikatów w trybie offline. Kroki 1–3 z tego miejsca zawierają przykład sposobu generowania tych plików.

  3. Utwórz wpisy tajne w usłudze Azure Key Vault przy użyciu certyfikatów i klucza:

    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>
    
  4. Włącz dostawcę usługi Azure Key Vault dla sterownika CSI magazynu wpisów tajnych dla klastra:

    az aks enable-addons --addons azure-keyvault-secrets-provider --resource-group $RESOURCE_GROUP --name $CLUSTER
    

    Uwaga

    Podczas rotacji certyfikatów, aby kontrolować, jak szybko wpisy tajne są synchronizowane z klastrem, możesz użyć --rotation-poll-interval parametru dodatku Dostawcy wpisów tajnych usługi Azure Key Vault. Na przykład: az aks addon update --resource-group $RESOURCE_GROUP --name $CLUSTER --addon azure-keyvault-secrets-provider --enable-secret-rotation --rotation-poll-interval 20s.

  5. Autoryzuj tożsamość zarządzaną przypisaną przez użytkownika dodatku, aby mieć dostęp do zasobu usługi 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
    

    Uwaga

    Jeśli utworzono usługę Key Vault przy użyciu autoryzacji RBAC platformy Azure dla modelu uprawnień zamiast zasad dostępu magazynu, postępuj zgodnie z instrukcjami podanymi tutaj , aby utworzyć uprawnienia dla tożsamości zarządzanej. Dodaj przypisanie roli platformy Azure dla Key Vault Reader tożsamości zarządzanej przypisanej przez użytkownika dodatku.

Konfigurowanie dodatku siatki usług opartej na systemie Istio przy użyciu certyfikatów urzędu certyfikacji wtyczek

  1. Włącz dodatek siatki usługi Istio dla istniejącego klastra usługi AKS podczas odwoływania się do utworzonych wcześniej wpisów tajnych usługi Azure Key Vault:

    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
    

    Uwaga

    W przypadku istniejących klastrów z dodatkiem Istio przy użyciu certyfikatu głównego z podpisem własnym generowanym przez urząd certyfikacji Istio przełączanie się do urzędu certyfikacji wtyczki nie jest obsługiwane. Najpierw należy wyłączyć siatkę w tych klastrach, a następnie włączyć ją ponownie za pomocą powyższego polecenia w celu przekazania danych wejściowych urzędu certyfikacji wtyczki.

  2. Sprawdź, czy plik cacerts został utworzony w klastrze:

    kubectl get secret -n aks-istio-system
    

    Oczekiwane dane wyjściowe:

    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. Sprawdź, czy płaszczyzna sterowania Istio odebrała niestandardowy urząd certyfikacji:

    kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system | grep -v validationController | grep x509
    

    Oczekiwane dane wyjściowe powinny być podobne do następujących:

    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"
    

Rotacja urzędu certyfikacji

Ze względów bezpieczeństwa lub zasad może być konieczne okresowe obracanie urzędów certyfikacji. W tej sekcji opisano sposób obsługi scenariuszy rotacji pośredniego urzędu certyfikacji i głównego urzędu certyfikacji.

Rotacja pośredniego urzędu certyfikacji

  1. Pośredni urząd certyfikacji można obrócić przy zachowaniu tego samego głównego urzędu certyfikacji. Zaktualizuj wpisy tajne w zasobie usługi Azure Key Vault przy użyciu nowych plików certyfikatów i kluczy:

    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. Poczekaj na czas trwania --rotation-poll-interval. Sprawdź, czy cacerts wpis tajny został odświeżony w klastrze na podstawie nowego pośredniego urzędu certyfikacji, który został zaktualizowany w zasobie usługi Azure Key Vault:

    kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system | grep -v validationController
    

    Oczekiwane dane wyjściowe powinny być podobne do następujących:

    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. Obciążenia otrzymują certyfikaty z płaszczyzny sterowania Istio, która jest domyślnie ważna przez 24 godziny. Jeśli nie uruchomisz ponownie zasobników, wszystkie obciążenia uzyskają nowe certyfikaty liścia na podstawie nowego pośredniego urzędu certyfikacji w ciągu 24 godzin. Jeśli chcesz wymusić na wszystkich tych obciążeniach uzyskanie nowych certyfikatów liścia od razu od nowego pośredniego urzędu certyfikacji, należy ponownie uruchomić obciążenia.

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>
    

Rotacja głównego urzędu certyfikacji

  1. Należy zaktualizować wpisy tajne usługi Azure Key Vault przy użyciu pliku certyfikatu głównego, który łączy stare i nowe certyfikaty główne:

    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>
    

    Zawartość następującego root-cert.pem formatu:

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

    Dodatek zawiera CronJob uruchamianie co dziesięć minut w klastrze, aby sprawdzić dostępność aktualizacji certyfikatu głównego. Jeśli wykryje aktualizację, uruchomi ponownie płaszczyznę sterowania Istio (istiod wdrożenie), aby pobrać aktualizacje. Możesz sprawdzić jego dzienniki, aby potwierdzić, że wykryto aktualizację certyfikatu głównego i czy płaszczyzna sterowania Istio została ponownie uruchomiona:

    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}')
    

    Oczekiwane dane wyjściowe:

    Root certificate update detected. Restarting deployment...
    deployment.apps/istiod-asm-1-17 restarted
    Deployment istiod-asm-1-17 restarted.
    

    Po istiod ponownym uruchomieniu należy wskazać, że do domeny zaufania zostały dodane dwa certyfikaty:

    kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system 
    

    Oczekiwane dane wyjściowe:

    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. Musisz poczekać 24 godziny (domyślny czas ważności certyfikatu liścia) lub wymusić ponowne uruchomienie wszystkich obciążeń. Dzięki temu wszystkie obciążenia rozpoznają zarówno stare, jak i nowe urzędy certyfikacji na potrzeby weryfikacji mTLS.

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>
    
  3. Teraz możesz zaktualizować wpisy tajne usługi Azure Key Vault tylko przy użyciu nowego urzędu certyfikacji (bez starego urzędu certyfikacji):

    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>
    

    Sprawdź dzienniki programu , CronJob aby potwierdzić wykrywanie aktualizacji certyfikatu głównego i ponowne uruchomienie programu 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}')
    

    Oczekiwane dane wyjściowe:

    Root certificate update detected. Restarting deployment...
    deployment.apps/istiod-asm-1-17 restarted
    Deployment istiod-asm-1-17 restarted.
    

    Po istiod zaktualizowaniu powinien on potwierdzić tylko użycie nowego głównego urzędu certyfikacji:

    kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system | grep -v validationController
    

    Oczekiwane dane wyjściowe:

    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"
    

    Z przykładowych danych wyjściowych przedstawionych w tym artykule można zaobserwować, że przenieśliśmy się z głównego A (używanego podczas włączania dodatku) do katalogu głównego B.

  4. Możesz ponownie poczekać 24 godziny lub wymusić ponowne uruchomienie wszystkich obciążeń. Wymuszanie ponownego uruchomienia sprawia, że obciążenia natychmiast uzyskują nowe certyfikaty liścia z nowego głównego urzędu certyfikacji.

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>