Problembehandlung beim Azure Key Vault Secrets Provider-Add-On in AKS

Artikel
12/13/2024

In diesem Artikel wird erläutert, wie Sie Probleme behandeln, die beim Verwenden des Azure Key Vault Secrets Provider-Add-Ons in Azure Kubernetes Service (AKS) auftreten können.

Notiz

Dieser Artikel bezieht sich auf die von AKS verwaltete Add-On-Version des Azure Key Vault Secrets Provider. Wenn Sie die installierte (selbstverwaltete) Version des Helms verwenden, wechseln Sie zur GitHub-Dokumentation des Azure Key Vault-Anbieters für Den geheimen Store-CSI-Treiber .

Voraussetzungen

Azure-Befehlszeilenschnittstelle
Das Kubernetes kubectl-Tool (Um Kubectl mithilfe von Azure CLI zu installieren, führen Sie den Befehl "az aks install-cli " aus.)
Das Kubernetes Secrets Store-CSI-Treiber-Add-On , aktiviert auf dem AKS-Cluster
Das Client-URL-Tool (curl)
Das Befehlszeilentool Netcat (nc) für TCP-Verbindungen

Checkliste zur Problembehandlung

Schritt 1: Bestätigen Sie, dass das Azure Key Vault Secrets Provider-Add-On auf Ihrem Cluster aktiviert ist

Führen Sie den Befehl "az aks show" aus, um zu bestätigen, dass das Add-On auf Ihrem Cluster aktiviert ist:

az aks show -g <aks-resource-group-name> -n <aks-name> --query 'addonProfiles.azureKeyvaultSecretsProvider'

Die Befehlsausgabe sollte dem folgenden Text ähneln:

{
  "config": null,
  "enabled": true,
  "identity": {
    "clientId": "<client-id>",
    "objectId": "<object-id>",
    "resourceId": "/subscriptions/<subscription-id>/resourcegroups/<resource-group-name>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<azure-key-vault-secrets-provider-identity-name>"
  }
}

Wenn das enabled Flag wie false in der vorherigen Ausgabe angezeigt wird, ist das Azure Key Vault Secrets Provider-Add-On nicht auf Ihrem Cluster aktiviert. Weitere Problembehandlung finden Sie in diesem Fall im Azure Key Vault-Anbieter für den CSI-Treiber des CSI-Treibers von Secrets Store.

Wenn das enabled Flag wie true in der vorherigen Ausgabe angezeigt wird, ist das Azure Key Vault Secrets Provider-Add-On auf Ihrem Cluster aktiviert. Gehen Sie in diesem Fall zu den nächsten Schritten in diesem Artikel.

Schritt 2: Überprüfen der Protokolle des Geheimspeicheranbieters und des CSI-Treibers

Azure Key Vault Secrets Provider-Add-On-Protokolle werden von Anbieter- und Treiber-Pods generiert. Um Probleme zu beheben, die sich auf den Anbieter oder Treiber auswirken, überprüfen Sie die Protokolle des Pods, der auf demselben Knoten wie Ihr Anwendungs pod ausgeführt wird.

Führen Sie den Befehl "kubectl get " aus, um die Pods "Secrets Store Provider" und "CSI-Treiber" zu finden, die auf demselben Knoten ausgeführt werden, auf dem Ihre Anwendungs-Pod ausgeführt wird:
```
kubectl get pod -l 'app in (secrets-store-provider-azure, secrets-store-csi-driver)' -n kube-system -o wide
```
Führen Sie den Befehl "Kubectl-Protokolle " aus, um Protokolle aus dem Pod für den Geheimspeicheranbieter anzuzeigen:
```
kubectl logs -n kube-system <provider-pod-name> --since=1h | grep ^E
```
Führen Sie den Befehl "Kubectl-Protokolle " aus, um Protokolle aus dem CSI-Treiber-Pod des Geheimspeichers anzuzeigen:
```
kubectl logs -n kube-system <csi-driver-pod-name> -c secrets-store --since=1h | grep ^E
```

Nachdem Sie die Protokolle des Geheimspeicheranbieters und des CSI-Treibers gesammelt haben, analysieren Sie diese Protokolle anhand der in den folgenden Abschnitten erwähnten Ursachen, um das Problem und die entsprechende Lösung zu identifizieren.

Notiz

Wenn Sie eine Supportanfrage öffnen, sollten Sie die relevanten Protokolle des Azure Key Vault-Anbieters und des CSI-Treibers für den Geheimspeicher einschließen.

Ursache 1: Das Schlüsseltresor-Token konnte nicht abgerufen werden

Möglicherweise wird der folgende Fehlereintrag in den Protokollen oder Ereignismeldungen angezeigt:

Warnung failedMount 74s kubelet MountVolume.SetUp failed for volume "secrets-store-inline" : kubernetes.io/csi: mounter. SetupAt failed: rpc error: code = Unknown desc = failed to mount secrets store objects for pod default/test, err: rpc error: code = Unknown desc = failed to mount objects, error: failed to get keyvault client: failed to get key vault token: nmi response failed with status code: 404, err: <nil>

Dieser Fehler tritt auf, da eine Node Managed Identity (NMI)-Komponente in aad-pod-identity eine Fehlermeldung über eine Tokenanforderung zurückgegeben hat.

Lösung 1: Überprüfen der NMI-Podprotokolle

Weitere Informationen zu diesem Fehler und zur Behebung dieses Fehlers finden Sie in den NMI-Podprotokollen und im Leitfaden zur Problembehandlung bei microsoft Entra-Pod-Identitäten.

Ursache 2: Der Anbieter-Pod kann nicht auf die Schlüsseltresorinstanz zugreifen

Möglicherweise wird der folgende Fehlereintrag in den Protokollen oder Ereignismeldungen angezeigt:

E1029 17:37:42.461313 1 server.go:54] fehler beim Verarbeiten der Bereitstellungsanforderung, Fehler: keyvault. BaseClient#GetSecret: Fehler beim Senden der Anforderung: StatusCode=0 -- Originalfehler: Kontextfrist überschritten

Dieser Fehler tritt auf, da der Anbieter-Pod nicht auf die Schlüsseltresorinstanz zugreifen kann. Der Zugriff kann aus folgenden Gründen verhindert werden:

Eine Firewallregel blockiert den ausgehenden Datenverkehr des Anbieters.
Netzwerkrichtlinien, die im AKS-Cluster konfiguriert sind, blockieren ausgehenden Datenverkehr.
Die Anbieter-Pods werden im Hostnetzwerk ausgeführt. Wenn eine Richtlinie diesen Datenverkehr blockiert oder Netzwerk-Jitters auf dem Knoten auftreten, kann ein Fehler auftreten.

Lösung 2: Überprüfen von Netzwerkrichtlinien, Zulassungslisten und Knotenverbindung

Führen Sie die folgenden Aktionen aus, um das Problem zu beheben:

Platzieren Sie die Anbieter-Pods auf der Zulassungsliste.
Überprüfen Sie auf Richtlinien, die für das Blockieren des Datenverkehrs konfiguriert sind.
Stellen Sie sicher, dass der Knoten über Eine Verbindung mit der Microsoft Entra-ID und Ihrem Schlüsseltresor verfügt.

Führen Sie die folgenden Schritte aus, um die Konnektivität mit Ihrem Azure Key Vault über den Pod zu testen, der im Hostnetzwerk ausgeführt wird:

Erstellen des Pods:

cat <<EOF | kubectl apply --filename -
apiVersion: v1
kind: Pod
metadata:
  name: curl
spec:
  hostNetwork: true
  containers:
  - args:
    - tail
    - -f
    - /dev/null
    image: curlimages/curl:7.75.0
    name: curl
  dnsPolicy: ClusterFirst
  restartPolicy: Always
EOF

Führen Sie kubectl exec aus, um einen Befehl in dem von Ihnen erstellten Pod auszuführen:
```
kubectl exec --stdin --tty  curl -- sh
```

Authentifizieren Sie sich mit Ihrem Azure Key Vault:

curl -X POST 'https://login.microsoftonline.com/<aad-tenant-id>/oauth2/v2.0/token' \
     -d 'grant_type=client_credentials&client_id=<azure-client-id>&client_secret=<azure-client-secret>&scope=https://vault.azure.net/.default'

Versuchen Sie, einen geheimen Schlüssel zu erhalten, der bereits in Ihrem Azure Key Vault erstellt wurde:

curl -X GET 'https://<key-vault-name>.vault.azure.net/secrets/<secret-name>?api-version=7.2' \
     -H "Authorization: Bearer <access-token-acquired-above>"

Ursache 3: Die vom Benutzer zugewiesene verwaltete Identität in der benutzerdefinierten Ressource SecretProviderClass ist falsch

Wenn eine HTTP-Fehlercodeinstanz "400" auftritt, die von einer Fehlerbeschreibung "Identität nicht gefunden" begleitet wird, ist die vom Benutzer zugewiesene verwaltete Identität in Ihrer SecretProviderClass benutzerdefinierten Ressource falsch. Die vollständige Antwort ähnelt dem folgenden Text:

MountVolume.SetUp failed for volume "<volume-name>" :  
  rpc error:  
    code = Unknown desc = failed to mount secrets store objects for pod <namespace>/<pod>,  
    err: rpc error: code = Unknown desc = failed to mount objects,  
    error: failed to get objectType:secret, objectName:<key-vault-secret-name>, objectVersion:: azure.BearerAuthorizer#WithAuthorization:  
      Failed to refresh the Token for request to https://<key-vault-name>.vault.azure.net/secrets/<key-vault-secret-name>/?api-version=2016-10-01:  
        StatusCode=400 -- Original Error: adal: Refresh request failed.  
        Status Code = '400'.  
        Response body: {"error":"invalid_request","error_description":"Identity not found"}  
        Endpoint http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&client_id=<userAssignedIdentityID>&resource=https%!!(MISSING)A(MISSING)%!!(MISSING)F(MISSING)%!!(MISSING)F(MISSING)vault.azure.net

Lösung 3: Aktualisieren von SecretProviderClass mithilfe des richtigen UserAssignedIdentityID-Werts

Suchen Sie die richtige vom Benutzer zugewiesene verwaltete Identität, und aktualisieren Sie dann die SecretProviderClass benutzerdefinierte Ressource, um den richtigen Wert im userAssignedIdentityID Parameter anzugeben. Um die richtige vom Benutzer zugewiesene verwaltete Identität zu finden, führen Sie den folgenden Befehl "Az aks show" in Azure CLI aus :

az aks show --resource-group <resource-group-name> \
    --name <cluster-name> \
    --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId \
    --output tsv

Informationen zum Einrichten einer SecretProviderClass benutzerdefinierten Ressource im YAML-Format finden Sie im Abschnitt "Verwenden einer vom Benutzer zugewiesenen verwalteten Identität " des Artikels "Bereitstellen einer Identität für den Zugriff auf den Azure Key Vault Provider for Secrets Store CSI Driver ".

Ursache 4: Der private Key Vault-Endpunkt befindet sich in einem anderen virtuellen Netzwerk als die AKS-Knoten

Der Zugriff auf öffentliche Netzwerke ist auf Azure Key Vault-Ebene nicht zulässig, und die Verbindung zwischen AKS und Key Vault erfolgt über eine private Verbindung. Die AKS-Knoten und der private Endpunkt des Key Vault befinden sich jedoch in verschiedenen virtuellen Netzwerken. In diesem Szenario wird eine Meldung generiert, die dem folgenden Text ähnelt:

MountVolume.SetUp failed for volume "<volume>" :  
  rpc error:  
    code = Unknown desc = failed to mount secrets store objects for pod <namespace>/<pod>,  
    err: rpc error: code = Unknown desc = failed to mount objects,  
    error: failed to get objectType:secret, objectName: :<key-vault-secret-name>, objectVersion:: keyvault.BaseClient#GetSecret:  
      Failure responding to request:  
        StatusCode=403 -- Original Error: autorest/azure: Service returned an error.  
        Status=403 Code="Forbidden"  
        Message="Public network access is disabled and request is not from a trusted service nor via an approved private link.\r\n  
        Caller: appid=<application-id>;oid=<object-id>;iss=https://sts.windows.net/<id>/;xms_mirid=/subscriptions/<subscription-id>/resourcegroups/<aks-infrastructure-resource-group>/providers/Microsoft.Compute/virtualMachineScaleSets/aks-<nodepool-name>-<nodepool-id>-vmss;xms_az_rid=/subscriptions/<subscription-id>/resourcegroups/<aks-infrastructure-resource-group>/providers/Microsoft.Compute/virtualMachineScaleSets/aks-<nodepool-name>-<nodepool-id>-vmss \r\n  
        Vault: <keyvaultname>;location=<location>" InnerError={"code":"ForbiddenByConnection"}

Lösung 4a: Einrichten einer virtuellen Netzwerkverbindung und eines virtuellen Netzwerk-Peerings zum Verbinden der virtuellen Netzwerke

Das Beheben des Konnektivitätsproblems ist im Allgemeinen ein zweistufiger Prozess:

Erstellen Sie eine virtuelle Netzwerkverbindung für das virtuelle Netzwerk des AKS-Clusters auf der privaten Azure DNS-Zonenebene .
Fügen Sie virtuelles Netzwerk-Peering zwischen dem virtuellen Netzwerk des AKS-Clusters und dem virtuellen Netzwerk des privaten Key Vault-Endpunkts hinzu.

Diese Schritte werden in den folgenden Abschnitten ausführlicher beschrieben.

Schritt 1: Erstellen der Virtuellen Netzwerkverbindung

Stellen Sie eine Verbindung mit den AKS-Clusterknoten her, um zu ermitteln, ob der vollqualifizierte Domänenname (FQDN) des Key Vault über eine öffentliche IP-Adresse oder eine private IP-Adresse aufgelöst wird. Wenn Sie die Fehlermeldung "Der Zugriff auf öffentliche Netzwerke ist deaktiviert, und die Anforderung stammt nicht von einem vertrauenswürdigen Dienst oder über einen genehmigten privaten Link", wird der Key Vault-Endpunkt wahrscheinlich über eine öffentliche IP-Adresse aufgelöst. Führen Sie den Befehl "nslookup " aus, um nach diesem Szenario zu suchen:

nslookup <key-vault-name>.vault.azure.net

Wenn der FQDN über eine öffentliche IP-Adresse aufgelöst wird, ähnelt die Befehlsausgabe dem folgenden Text:

root@aks-<nodepool-name>-<nodepool-id>-vmss<scale-set-instance>:/# nslookup <key-vault-name>.vault.azure.net
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
<key-vault-name>.vault.azure.net  canonical name = <key-vault-name>.privatelink.vaultcore.azure.net.
<key-vault-name>.privatelink.vaultcore.azure.net  canonical name = data-prod.weu.vaultcore.azure.net.
data-prod-weu.vaultcore.azure.net  canonical name = data-prod-weu-region.vaultcore.azure.net.
data-prod-weu-region.vaultcore.azure.net  canonical name = azkms-prod-weu-b.westeurope.cloudapp.azure.com.
Name:   azkms-prod-weu-b.westeurope.cloudapp.azure.com
Address: 20.1.2.3

Erstellen Sie in diesem Fall eine virtuelle Netzwerkverbindung für das virtuelle Netzwerk des AKS-Clusters auf der Ebene der privaten DNS-Zone. (Für das virtuelle Netzwerk des privaten Key Vault-Endpunkts wird bereits automatisch eine virtuelle Netzwerkverbindung erstellt.)

Führen Sie die folgenden Schritte aus, um eine virtuelle Netzwerkverbindung zu erstellen:

Suchen Sie im Azure-Portal nach Privates DNS Zonen, und wählen Sie sie aus.
Wählen Sie in der Liste der privaten DNS-Zonen den Namen Ihrer privaten DNS-Zone aus. In diesem Beispiel wird die private DNS-Zone privatelink.vaultcore.azure.net.
Suchen Sie im Navigationsbereich der privaten DNS-Zone nach der Überschrift "Einstellungen ", und wählen Sie dann virtuelle Netzwerklinks aus.
Wählen Sie in der Liste der virtuellen Netzwerklinks "Hinzufügen" aus.

Füllen Sie auf der Seite "Virtuelle Netzwerkverbindung hinzufügen" die folgenden Felder aus.

Feldname	Aktion
Linkname	Geben Sie einen Namen ein, der für die virtuelle Netzwerkverbindung verwendet werden soll.
Abonnement	Wählen Sie den Namen des Abonnements aus, das Sie den virtuellen Netzwerklink enthalten möchten.
Virtuelles Netzwerk	Wählen Sie den Namen des virtuellen Netzwerks des AKS-Clusters aus.

Wählen Sie die Schaltfläche OK aus.

Nachdem Sie die Verknüpfungserstellungsprozedur abgeschlossen haben, führen Sie den nslookup Befehl aus. Die Ausgabe sollte nun dem folgenden Text ähneln, der eine direktere DNS-Auflösung anzeigt:

root@aks-<nodepool-name>-<nodepool-id>-vmss<scale-set-instance>:/# nslookup <key-vault-name>.vault.azure.net
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
<key-vault-name>.vault.azure.net  canonical name = <key-vault-name>.privatelink.vaultcore.azure.net.
Name:   <key-vault-name>.privatelink.vaultcore.azure.net
Address: 172.20.0.4

Nachdem die virtuelle Netzwerkverbindung hinzugefügt wurde, sollte der FQDN über eine private IP-Adresse aufgelöst werden können.

Schritt 2: Hinzufügen eines virtuellen Netzwerk-Peerings zwischen virtuellen Netzwerken

Wenn Sie einen privaten Endpunkt verwenden, haben Sie wahrscheinlich den öffentlichen Zugriff auf Key Vault-Ebene deaktiviert. Daher besteht keine Verbindung zwischen AKS und dem Key Vault. Sie können diese Konfiguration mit dem folgenden Netcat (nc)-Befehl testen:

nc -v -w 2 <key-vault-name>.vault.azure.net 443

Wenn die Verbindung zwischen AKS und dem Key Vault nicht verfügbar ist, wird die Ausgabe angezeigt, die dem folgenden Text ähnelt:

nc: connect to <key-vault-name>.vault.azure.net port 443 (tcp) timed out: Operation now in progress

Um die Verbindung zwischen AKS und dem Key Vault herzustellen, fügen Sie virtuelles Netzwerk-Peering zwischen den virtuellen Netzwerken hinzu, indem Sie die folgenden Schritte ausführen:

Öffnen Sie das Azure-Portal.
Verwenden Sie eine der folgenden Optionen, um die Anweisungen aus dem Abschnitt "Virtuelles Netzwerk peer erstellen" des Lernprogramms zu befolgen: Verbinden sie virtuelle Netzwerke mit virtuellem Netzwerk-Peering mithilfe des Artikels Azure-Portal, um die virtuellen Netzwerke zu peeren und zu überprüfen, ob die virtuellen Netzwerke verbunden sind (von einem Ende):
- Wechseln Sie zu Ihrem virtuellen AKS-Netzwerk, und peeren Sie es mit dem virtuellen Netzwerk des privaten Key Vault-Endpunkts.
- Wechseln Sie zum virtuellen Netzwerk des privaten Key Vault-Endpunkts, und peeren Sie es mit dem virtuellen AKS-Netzwerk.
Suchen Sie im Azure-Portal nach dem Namen des anderen virtuellen Netzwerks (dem virtuellen Netzwerk, mit dem Sie im vorherigen Schritt peered haben).
Suchen Sie im Navigationsbereich des virtuellen Netzwerks nach der Überschrift "Einstellungen", und wählen Sie dann "Peerings" aus.
Vergewissern Sie sich auf der Seite "Virtuelles Netzwerk-Peering", dass die Spalte "Name " den Namen des virtuellen Remotenetzwerks enthält, das Sie in Schritt 2 angegeben haben. Stellen Sie außerdem sicher, dass die Spalte "Peeringstatus " für diesen Peeringlink den Wert "Verbunden" aufweist.

Nachdem Sie dieses Verfahren abgeschlossen haben, können Sie den Netcat-Befehl erneut ausführen. Die DNS-Auflösung und Konnektivität zwischen AKS und dem Key Vault sollte jetzt erfolgreich sein. Stellen Sie außerdem sicher, dass die Schlüsseltresorschlüssel erfolgreich bereitgestellt werden und wie erwartet funktionieren, wie in der folgenden Ausgabe dargestellt:

Connection to <key-vault-name>.vault.azure.net 443 port [tcp/https] succeeded!

Lösung 4b: Problembehandlung bei Fehlercode 403

Problembehandlung beim Fehlercode "403", indem Sie den Abschnitt "HTTP 403: Unzureichende Berechtigungen" des Referenzartikels zu Fehlercodes der Azure Key Vault-REST-API überprüfen.

Ursache 5: Der secrets-store.csi.k8s.io Treiber fehlt in der Liste der registrierten CSI-Treiber

Wenn Sie die folgende Fehlermeldung über einen fehlenden secrets-store.csi.k8s.io Treiber in den Pod-Ereignissen erhalten, werden die CSI-Treiber pods des Secrets Store nicht auf dem Knoten ausgeführt, in dem die Anwendung ausgeführt wird:

Warning FailedMount 42s (x12 over 8m56s) kubelet, akswin0000000 MountVolume.SetUp failed for volume "secrets-store01-inline" : kubernetes.io/csi: mounter. SetUpAt konnte den CSI-Client nicht abrufen: Treibername secrets-store.csi.k8s.io in der Liste der registrierten CSI-Treiber nicht gefunden

Lösung 5: Problembehandlung für den CSI-Treiber-Pod des geheimen Speichers, der auf demselben Knoten ausgeführt wird

Rufen Sie den Status des CSI-Treiber-Pods des geheimen Speichers ab, der auf demselben Knoten ausgeführt wird, indem Sie den folgenden Befehl ausführen:

kubectl get pod -l app=secrets-store-csi-driver -n kube-system -o wide

Wenn der Pod-Status nicht Running oder eines der Container in diesem Pod nicht im Ready Zustand ist, fahren Sie mit dem Überprüfen der Protokolle für diesen Pod fort, indem Sie die Schritte in den Protokollen des Geheimspeicheranbieters und des CSI-Treibers ausführen.

Ursache 6: SecretProviderClass nicht gefunden

Möglicherweise wird das folgende Ereignis beim Beschreiben Ihres Anwendungs-Pods angezeigt:

Events:
  Type     Reason       Age               From               Message
  ----     ------       ----              ----               -------
  Warning  FailedMount  2s (x5 over 10s)  kubelet            MountVolume.SetUp failed for volume "xxxxxxx" : rpc error: code = Unknown desc = failed to get secretproviderclass xxxxxxx/xxxxxxx, error: SecretProviderClass.secrets-store.csi.x-k8s.io "xxxxxxxxxxxxx" not found

Dieses Ereignis gibt an, dass der Verweis in der SecretProviderClass Volumespezifikation Ihres Pods nicht im selben Namespace wie Ihr Anwendungs pod vorhanden ist.

Lösung 6a: Erstellen der fehlenden SecretProviderClass-Ressource

Stellen Sie sicher, dass die Ressource, auf die in der SecretProviderClass Volumespezifikation Ihrer Pod verwiesen wird, im selben Namespace vorhanden ist, in dem Ihr Anwendungs-Pod ausgeführt wird.

Lösung 6b: Ändern der Volumespezifikation Ihres Anwendungs pods, um auf den richtigen Ressourcennamen "SecretProviderClass" zu verweisen

Bearbeiten Sie die Volumespezifikation Ihres Anwendungs pods, um auf den richtigen SecretProviderClass Ressourcennamen zu verweisen:

...
spec:
  containers:
  ...
  volumes:
    - name: my-volume
      csi:
        driver: secrets-store.csi.k8s.io
        readOnly: true
        volumeAttributes:
          secretProviderClass: "xxxxxxxxx"

Ursache 7: Die Anforderung ist nicht authentifiziert.

Die Anforderung ist für Key Vault nicht authentifiziert, wie durch einen Fehlercode "401" angegeben.

Lösung 7: Problembehandlung bei Fehlercode 401

Problembehandlung beim Fehlercode "401", indem Sie den Abschnitt "HTTP 401: Nicht authentifizierte Anforderung" des Referenzartikels zu Fehlercodes der Azure Key Vault-REST-API überprüfen.

Ursache 8: Die Anzahl der Anforderungen überschreitet das angegebene Maximum.

Die Anzahl der Anforderungen überschreitet das angegebene Maximum für den Zeitrahmen, wie durch einen Fehlercode "429" angegeben.

Lösung 8: Problembehandlung bei Fehlercode 429

Problembehandlung beim Fehlercode "429", indem Sie den Abschnitt "HTTP 429: Too Many Requests" des Referenzartikels zu Fehlercodes der Azure Key Vault-REST-API überprüfen.

Informationen zum Haftungsausschluss von Drittanbietern

Die in diesem Artikel genannten Drittanbieterprodukte stammen von Herstellern, die von Microsoft unabhängig sind. Microsoft gewährt keine implizite oder sonstige Garantie in Bezug auf die Leistung oder Zuverlässigkeit dieser Produkte.

Kontaktieren Sie uns für Hilfe

Wenn Sie Fragen haben oder Hilfe mit Ihren Azure-Gutschriften benötigen, dann erstellen Sie beim Azure-Support eine Support-Anforderung oder fragen Sie den Azure Community-Support. Sie können auch Produktfeedback an die Azure Feedback Community senden.

Freigeben über