Freigeben über


Plug-In-Zertifizierungsstellenzertifikate für das Istio-basierte Servicenetz-Add-On für Azure Kubernetes Service

Beim Istio-basierten Servicenetz-Add-On für Azure Kubernetes Service generiert die Istio-Zertifizierungsstelle (Certificate Authority, CA) standardmäßig ein selbstsigniertes Stammzertifikat sowie einen selbstsignierten Schlüssel und verwendet diese zum Signieren der Workloadzertifikate. Um den Stammzertifizierungsstellen-Schlüssel zu schützen, sollten Sie eine Stammzertifizierungsstelle verwenden, die offline auf einem sicheren Computer ausgeführt wird. Sie können die Stammzertifizierungsstelle verwenden, um Zwischenzertifikate für die Istio-Zertifizierungsstellen auszustellen, die in jedem Cluster ausgeführt werden. Eine Istio-Zertifizierungsstelle kann Workloadzertifikate mit dem von den Administratoren angegebenen Zertifikat und Schlüssel signieren und ein von den Administratoren angegebenes Stammzertifikat als Vertrauensanker an die Workloads verteilen. In diesem Artikel wird beschrieben, wie Sie Ihre eigenen Zertifikate und Schlüssel für die Istio-Zertifizierungsstelle im Istio-basierten Servicenetz-Add-On für Azure Kubernetes Service verwenden.

Diagramm: Stamm- und Zwischenzertifizierungsstelle mit Istio

In diesem Artikel wird beschrieben, wie Sie mithilfe von Azure Key Vault die Istio-Zertifizierungsstelle mit einem Stammzertifikat, Signaturzertifikat und Schlüssel als Eingaben für das Istio-basierte Servicenetz-Add-On konfigurieren können.

Voraussetzungen

Überprüfen der Azure CLI-Version

Für das Add-On muss die Azure CLI-Version 2.57.0 oder neuer installiert sein. Sie können az --version ausführen, um die Version zu überprüfen. Informationen zum Installieren oder Aktualisieren finden Sie unter [Installieren der Azure-Befehlszeilenschnittstelle][azure-cli-install].

Einrichten von Azure Key Vault

  1. Sie benötigen eine Azure Key Vault-Ressource, um das Zertifikat und die Schlüsseleingaben für das Istio-Add-On bereitstellen zu können.

  2. Sie müssen ein Stammzertifikat, Zwischenzertifikate, einen Zwischenschlüssel und die Zertifikatkette offline generieren. Die Schritte 1 bis 3 aus diesem Abschnitt veranschaulichen das Generieren dieser Dateien.

  3. Erstellen Sie Geheimnisse in Azure Key Vault mithilfe der Zertifikate und des Schlüssels:

    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. Aktivieren Sie den Azure Key Vault-Anbieter für den Geheimnisspeicher-CSI-Treiber für Ihren Cluster:

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

    Hinweis

    Wenn Sie Zertifikate rotieren, können Sie mit dem --rotation-poll-interval-Parameter des Azure Key Vault-Geheimnisanbieter-Add-Ons steuern, wie schnell die Geheimnisse mit dem Cluster synchronisiert werden. Beispiel: az aks addon update --resource-group $RESOURCE_GROUP --name $CLUSTER --addon azure-keyvault-secrets-provider --enable-secret-rotation --rotation-poll-interval 20s

  5. Autorisieren Sie die benutzerseitig zugewiesene verwaltete Identität des Add-Ons, um Zugriff auf die Azure Key Vault-Ressource zu erhalten:

    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
    

    Hinweis

    Wenn Sie Ihren Key Vault mit Azure RBAC-Autorisierung für Ihr Berechtigungsmodell anstelle der Tresorzugriffsrichtlinie erstellt haben, befolgen Sie die hier aufgeführten Anweisungen, um Berechtigungen für die verwaltete Identität zu erstellen. Fügen Sie für die benutzerseitig zugewiesene verwaltete Identität des Add-Ons eine Azure-Rollenzuweisung für Key Vault Reader hinzu.

Einrichten eines Istio-basierten Servicenetz-Add-Ons mit Plug-In-Zertifizierungsstellenzertifikaten

  1. Aktivieren Sie das Istio-Servicenetz-Add-On für Ihren vorhandenen AKS-Cluster, während Sie auf die zuvor erstellten Azure Key Vault-Geheimnisse verweisen:

    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
    

    Hinweis

    Für vorhandene Cluster mit Istio-Add-On, das das von der Istio-Zertifizierungsstelle generierte selbstsignierte Stammzertifikat verwendet, wird der Wechsel zur Plug-In-Zertifizierungsstelle nicht unterstützt. Sie müssen das Netz für diese Cluster zuerst deaktivieren und dann wieder mit dem obigen Befehl aktivieren, um die Plug-In-Zertifizierungsstelleneingaben zu durchlaufen.

  2. Stellen Sie sicher, dass das cacerts-Element für den Cluster erstellt wird:

    kubectl get secret -n aks-istio-system
    

    Erwartete Ausgabe:

    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. Überprüfen Sie, ob die Istio-Steuerungsebene die benutzerdefinierte Zertifizierungsstelle aufgenommen hat:

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

    Die Ausgabe sollte in etwa wie folgt aussehen:

    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"
    

Rotation der Zertifizierungsstelle

Sie müssen die Zertifizierungsstellen aus Sicherheits- und Richtliniengründen ggf. in regelmäßigen Abständen rotieren. In diesem Abschnitt erfahren Sie, wie Sie Rotationsszenarios für Zwischenzertifizierungsstellen und Stammzertifizierungsstellen behandeln.

Rotation der Zwischenzertifizierungsstelle

  1. Sie können die Zwischenzertifizierungsstelle rotieren und gleichzeitig die Stammzertifizierungsstelle unverändert lassen. Aktualisieren Sie die Geheimnisse in der Azure Key Vault-Ressource mit den neuen Zertifikat- und Schlüsseldateien:

    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. Warten Sie die Dauer von --rotation-poll-interval ab. Überprüfen Sie, ob das Geheimnis cacerts im Cluster basierend auf der neuen Zwischenzertifizierungsstelle aktualisiert wurde, die für die Azure Key Vault-Ressource aktualisiert wurde:

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

    Die Ausgabe sollte in etwa wie folgt aussehen:

    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. Die Workloads erhalten Zertifikate von der Istio-Steuerungsebene, die standardmäßig 24 Stunden gültig sind. Wenn Sie die Pods nicht neu starten, erhalten alle Workloads basierend auf der neuen Zwischenzertifizierungsstelle in 24 Stunden neue untergeordnete Zertifikate. Wenn Sie erzwingen möchten, dass all diese Workloads sofort neue untergeordnete Zertifikate von der neuen Zwischenzertifizierungsstelle erhalten, müssen Sie die Workloads neu starten.

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

Rotation der Stammzertifizierungsstelle

  1. Sie müssen Azure Key Vault-Geheimnisse mit der Stammzertifikatdatei mit der Verkettung der alten und neuen Stammzertifikate aktualisieren:

    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>
    

    Der Inhalt von root-cert.pem folgt diesem Format:

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

    Das Add-On umfasst ein CronJob-Element, das alle zehn Minuten im Cluster ausgeführt wird, um die Verfügbarkeit von Updates für das Stammzertifikat zu überprüfen. Wenn ein Update ermittelt wird, wird die Istio-Steuerungsebene (istiod-Bereitstellung) neu gestartet, um die Updates aufzunehmen. Sie können die Protokolle einsehen, um zu überprüfen, ob das Stammzertifikatupdate erkannt und die Istio-Steuerungsebene neu gestartet wurde:

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

    Erwartete Ausgabe:

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

    Nach dem Neustart von istiod sollte angegeben werden, dass der Vertrauensdomäne zwei Zertifikate hinzugefügt wurden:

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

    Erwartete Ausgabe:

    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. Sie müssen entweder 24 Stunden warten (Standardzeit für die Gültigkeit des untergeordneten Zertifikats) oder einen Neustart aller Workloads erzwingen. Auf diese Weise erkennen alle Workloads sowohl die alte als auch die neuen Zertifizierungsstellen für die mTLS-Überprüfung.

    kubectl rollout restart deployment <deployment name> -n <deployment namespace>
    
  3. Sie können Azure Key Vault-Geheimnisse jetzt nur mit der neuen Zertifizierungsstelle (ohne die alte Zertifizierungsstelle) updaten:

    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>
    

    Überprüfen Sie die CronJob-Protokolle, um zu bestätigen, dass das Stammzertifikatupdate erkannt und istiod neu gestartet wurde:

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

    Erwartete Ausgabe:

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

    Nach dem Update von istiod sollte nur die Verwendung der neuen Stammzertifizierungsstelle bestätigt werden:

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

    Erwartete Ausgabe:

    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"
    

    Anhand der in diesem Artikel gezeigten Beispielausgaben können Sie erkennen, dass von „Root A“ (beim Aktivieren des Add-Ons verwendet) zu „Root B“ gewechselt wurde.

  4. Sie können erneut entweder 24 Stunden warten oder einen Neustart aller Workloads erzwingen. Durch das Erzwingen eines Neustarts erhalten die Workloads sofort neue untergeordnete Zertifikat von der neuen Stammzertifizierungsstelle.

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