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.
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
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.
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.
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/cert-chain.pem>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 $CLUSTERHinweis
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 20sAutorisieren 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 listHinweis
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 Readerhinzu.
Einrichten eines Istio-basierten Servicenetz-Add-Ons mit Plug-In-Zertifizierungsstellenzertifikaten
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_NAMEHinweis
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.
Stellen Sie sicher, dass das
cacerts-Element für den Cluster erstellt wird:kubectl get secret -n aks-istio-systemErwartete 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Ü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 x509Die 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
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>Warten Sie die Dauer von
--rotation-poll-intervalab. Überprüfen Sie, ob das Geheimniscacertsim 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 validationControllerDie 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 reloadedDie 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
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.pemfolgt 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
istiodsollte angegeben werden, dass der Vertrauensdomäne zwei Zertifikate hinzugefügt wurden:kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-systemErwartete 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 verifierSie 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>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 undistiodneu 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
istiodsollte nur die Verwendung der neuen Stammzertifizierungsstelle bestätigt werden:kubectl logs deploy/istiod-asm-1-17 -c discovery -n aks-istio-system | grep -v validationControllerErwartete 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.
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>