Rozwiązywanie problemów z dodatkiem dostawcy wpisów tajnych usługi Azure Key Vault w usłudze AKS
W tym artykule omówiono sposób rozwiązywania problemów, które mogą wystąpić podczas korzystania z dodatku dostawcy wpisów tajnych usługi Azure Key Vault w usłudze Azure Kubernetes Service (AKS).
Uwaga 16.
Ten artykuł dotyczy zarządzanej wersji dodatku usługi AKS dostawcy wpisów tajnych usługi Azure Key Vault. Jeśli używasz zainstalowanej (self-managed) wersji narzędzia Helm, przejdź do dokumentacji usługi Azure Key Vault dla magazynu wpisów tajnych csi sterownik GitHub.
Wymagania wstępne
Narzędzie Kubernetes kubectl (aby zainstalować narzędzie kubectl przy użyciu interfejsu wiersza polecenia platformy Azure, uruchom polecenie az aks install-cli ).
Dodatek sterownika CSI magazynu wpisów tajnych Kubernetes jest włączony w klastrze usługi AKS
Narzędzie adresu URL klienta (curl)
Narzędzie wiersza polecenia Netcat (
nc) dla połączeń TCP
Lista kontrolna rozwiązywania problemów
Krok 1. Upewnij się, że dodatek dostawcy wpisów tajnych usługi Azure Key Vault jest włączony w klastrze
Uruchom polecenie az aks show, aby potwierdzić, że dodatek jest włączony w klastrze:
az aks show -g <aks-resource-group-name> -n <aks-name> --query 'addonProfiles.azureKeyvaultSecretsProvider'
Dane wyjściowe polecenia powinny być podobne do następującego tekstu:
{
"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>"
}
}
Jeśli flaga enabled jest wyświetlana jak false w poprzednich danych wyjściowych, dodatek Dostawcy wpisów tajnych usługi Azure Key Vault nie jest włączony w klastrze. W tym przypadku zapoznaj się z dokumentacją dotyczącą dostawcy usługi Azure Key Vault dla sterownika CSI magazynu wpisów tajnych w witrynie GitHub, aby uzyskać dalsze informacje na temat rozwiązywania problemów.
Jeśli flaga enabled jest wyświetlana jak true w poprzednich danych wyjściowych, dodatek Dostawcy wpisów tajnych usługi Azure Key Vault jest włączony w klastrze. W tym przypadku przejdź do następnych kroków w tym artykule.
Krok 2. Sprawdzanie dzienników zasobnika magazynu wpisów tajnych i zasobników sterowników CSI
Dzienniki dodatku dostawcy wpisów tajnych usługi Azure Key Vault są generowane przez zasobniki dostawcy i sterownika. Aby rozwiązać problemy wpływające na dostawcę lub sterownik, sprawdź dzienniki z zasobnika uruchomionego w tym samym węźle co zasobnik aplikacji.
Uruchom polecenie kubectl get, aby znaleźć zasobniki dostawcy magazynu wpisów tajnych i sterowników CSI, które działają w tym samym węźle, na który działa zasobnik aplikacji:
kubectl get pod -l 'app in (secrets-store-provider-azure, secrets-store-csi-driver)' -n kube-system -o wideUruchom polecenie kubectl logs, aby wyświetlić dzienniki z zasobnika Dostawcy magazynu wpisów tajnych:
kubectl logs -n kube-system <provider-pod-name> --since=1h | grep ^EUruchom polecenie kubectl logs, aby wyświetlić dzienniki z zasobnika sterowników CSI magazynu wpisów tajnych:
kubectl logs -n kube-system <csi-driver-pod-name> -c secrets-store --since=1h | grep ^E
Po zebraniu dzienników zasobników dostawcy magazynu wpisów tajnych i zasobnika sterownika CSI przeanalizuj te dzienniki pod przyczynami wymienionymi w poniższych sekcjach, aby zidentyfikować problem i odpowiednie rozwiązanie.
Uwaga 16.
Jeśli otworzysz wniosek o pomoc techniczną, dobrym pomysłem jest dołączenie odpowiednich dzienników od dostawcy usługi Azure Key Vault i sterownika CSI magazynu wpisów tajnych.
Przyczyna 1: Nie można pobrać tokenu magazynu kluczy
W dziennikach lub komunikatach o zdarzeniach może zostać wyświetlony następujący wpis o błędzie:
Ostrzeżenie Niepowodzenie instalacji 74s kubelet MountVolume.SetUp nie powiodło się dla woluminu "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>
Ten błąd występuje, ponieważ składnik tożsamości zarządzanej węzła (NMI) w tożsamości aad-pod zwrócił komunikat o błędzie dotyczący żądania tokenu.
Rozwiązanie 1. Sprawdzanie dzienników zasobników NMI
Aby uzyskać więcej informacji na temat tego błędu i sposobu jego rozwiązania, zapoznaj się z dziennikami zasobnika NMI i zapoznaj się z przewodnikiem rozwiązywania problemów z tożsamością zasobnika firmy Microsoft Entra.
Przyczyna 2. Zasobnik dostawcy nie może uzyskać dostępu do wystąpienia magazynu kluczy
W dziennikach lub komunikatach o zdarzeniach może zostać wyświetlony następujący wpis o błędzie:
E1029 17:37:42.461313 1 server.go:54] nie może przetworzyć żądania instalacji, błąd: keyvault. BaseClient#GetSecret: Niepowodzenie wysyłania żądania: StatusCode=0 -- Oryginalny błąd: przekroczono termin ostateczny kontekstu
Ten błąd występuje, ponieważ zasobnik dostawcy nie może uzyskać dostępu do wystąpienia magazynu kluczy. Dostęp może być zabroniony z następujących powodów:
Reguła zapory blokuje ruch wychodzący od dostawcy.
Zasady sieciowe skonfigurowane w klastrze usługi AKS blokują ruch wychodzący.
Zasobniki dostawcy są uruchamiane w sieci hosta. Błąd może wystąpić, jeśli zasady blokują ten ruch lub jeśli na węźle wystąpią zakłócenia sieci.
Rozwiązanie 2. Sprawdzanie zasad sieciowych, listy dozwolonych i połączenia węzła
Aby rozwiązać ten problem, wykonaj następujące czynności:
Umieść zasobniki dostawcy na liście dozwolonych.
Sprawdź zasady skonfigurowane do blokowania ruchu.
Upewnij się, że węzeł ma łączność z identyfikatorem Entra firmy Microsoft i magazynem kluczy.
Aby przetestować łączność z magazynem kluczy platformy Azure z zasobnika uruchomionego w sieci hosta, wykonaj następujące kroki:
Utwórz zasobnik:
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 EOFUruchom polecenie kubectl exec , aby uruchomić polecenie w utworzonym zasobniku:
kubectl exec --stdin --tty curl -- shUwierzytelnianie przy użyciu magazynu kluczy platformy Azure:
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'Spróbuj uzyskać wpis tajny, który został już utworzony w magazynie kluczy platformy Azure:
curl -X GET 'https://<key-vault-name>.vault.azure.net/secrets/<secret-name>?api-version=7.2' \ -H "Authorization: Bearer <access-token-acquired-above>"
Przyczyna 3. Tożsamość zarządzana przypisana przez użytkownika w zasobie niestandardowym SecretProviderClass jest niepoprawna
Jeśli wystąpi wystąpienie błędu HTTP "400", któremu towarzyszy opis błędu "Nie znaleziono tożsamości", tożsamość zarządzana przypisana przez użytkownika jest niepoprawna w SecretProviderClass zasobie niestandardowym. Pełna odpowiedź przypomina następujący tekst:
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
Rozwiązanie 3. Aktualizowanie klasy SecretProviderClass przy użyciu poprawnej wartości userAssignedIdentityID
Znajdź poprawną tożsamość zarządzaną przypisaną przez użytkownika, a następnie zaktualizuj SecretProviderClass zasób niestandardowy, aby określić poprawną wartość w parametrze userAssignedIdentityID . Aby znaleźć poprawną tożsamość zarządzaną przypisaną przez użytkownika, uruchom następujące polecenie az aks show w interfejsie wiersza polecenia platformy Azure:
az aks show --resource-group <resource-group-name> \
--name <cluster-name> \
--query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId \
--output tsv
Aby uzyskać informacje o sposobie konfigurowania zasobu niestandardowego SecretProviderClass w formacie YAML, zobacz sekcję Używanie tożsamości zarządzanej przypisanej przez użytkownika w artykule Zapewnianie tożsamości w celu uzyskania dostępu do dostawcy usługi Azure Key Vault dla sterownika CSI magazynu wpisów tajnych.
Przyczyna 4. Prywatny punkt końcowy usługi Key Vault znajduje się w innej sieci wirtualnej niż węzły usługi AKS
Dostęp do sieci publicznej nie jest dozwolony na poziomie usługi Azure Key Vault, a łączność między usługą AKS i usługą Key Vault odbywa się za pośrednictwem łącza prywatnego. Jednak węzły usługi AKS i prywatny punkt końcowy usługi Key Vault znajdują się w różnych sieciach wirtualnych. Ten scenariusz generuje komunikat podobny do następującego tekstu:
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"}
Rozwiązanie 4a: Konfigurowanie połączenia sieci wirtualnej i komunikacji równorzędnej sieci wirtualnych w celu połączenia sieci wirtualnych
Rozwiązanie problemu z łącznością jest zazwyczaj procesem dwuetapowym:
Utwórz link sieci wirtualnej dla sieci wirtualnej klastra usługi AKS na poziomie prywatnej strefy DNS platformy Azure.
Dodaj komunikację równorzędną sieci wirtualnych między siecią wirtualną klastra AKS a siecią wirtualną prywatnego punktu końcowego usługi Key Vault.
Te kroki opisano bardziej szczegółowo w poniższych sekcjach.
Krok 1. Tworzenie łącza sieci wirtualnej
Połącz się z węzłami klastra usługi AKS, aby określić, czy w pełni kwalifikowana nazwa domeny (FQDN) usługi Key Vault jest rozpoznawana za pośrednictwem publicznego adresu IP lub prywatnego adresu IP. Jeśli zostanie wyświetlony komunikat o błędzie "Dostęp do sieci publicznej jest wyłączony i żądanie nie pochodzi z zaufanej usługi ani za pośrednictwem zatwierdzonego łącza prywatnego", punkt końcowy usługi Key Vault prawdopodobnie zostanie rozwiązany za pośrednictwem publicznego adresu IP. Aby sprawdzić ten scenariusz, uruchom polecenie nslookup :
nslookup <key-vault-name>.vault.azure.net
Jeśli nazwa FQDN jest rozpoznawana za pośrednictwem publicznego adresu IP, dane wyjściowe polecenia przypominają następujący tekst:
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
W takim przypadku utwórz link sieci wirtualnej dla sieci wirtualnej klastra usługi AKS na poziomie prywatnej strefy DNS. (Łącze sieci wirtualnej jest już tworzone automatycznie dla sieci wirtualnej prywatnego punktu końcowego usługi Key Vault).
Aby utworzyć link do sieci wirtualnej, wykonaj następujące kroki:
W witrynie Azure Portal wyszukaj i wybierz strefy Prywatna strefa DNS.
Na liście prywatnych stref DNS wybierz nazwę prywatnej strefy DNS. W tym przykładzie prywatna strefa DNS jest privatelink.vaultcore.azure.net.
W okienku nawigacji prywatnej strefy DNS znajdź nagłówek Ustawienia , a następnie wybierz pozycję Łącza sieci wirtualnej.
Na liście linków sieci wirtualnej wybierz pozycję Dodaj.
Na stronie Link dodaj sieć wirtualną wypełnij następujące pola.
Nazwa pola Akcja Nazwa łącza Wprowadź nazwę, która ma być używana dla linku sieci wirtualnej. Subskrypcja Wybierz nazwę subskrypcji, która ma zawierać link sieci wirtualnej. Sieć wirtualna Wybierz nazwę sieci wirtualnej klastra usługi AKS. Wybierz przycisk OK.
Po zakończeniu procedury tworzenia linku nslookup uruchom polecenie . Dane wyjściowe powinny teraz przypominać następujący tekst, który pokazuje bardziej bezpośrednie rozpoznawanie nazw DNS:
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
Po dodaniu linku sieci wirtualnej nazwa FQDN powinna być rozpoznawana za pośrednictwem prywatnego adresu IP.
Krok 2. Dodawanie komunikacji równorzędnej sieci wirtualnych między sieciami wirtualnymi
Jeśli używasz prywatnego punktu końcowego, prawdopodobnie wyłączono dostęp publiczny na poziomie usługi Key Vault. W związku z tym żadna łączność między usługą AKS i usługą Key Vault nie istnieje. Konfigurację można przetestować przy użyciu następującego polecenia Netcat (nc):
nc -v -w 2 <key-vault-name>.vault.azure.net 443
Jeśli łączność między usługą AKS i usługą Key Vault nie jest dostępna, zobaczysz dane wyjściowe podobne do następującego tekstu:
nc: connect to <key-vault-name>.vault.azure.net port 443 (tcp) timed out: Operation now in progress
Aby ustanowić łączność między usługą AKS i usługą Key Vault, dodaj komunikację równorzędną sieci wirtualnych między sieciami wirtualnymi, wykonując następujące kroki:
Przejdź do portalu Azure Portal.
Użyj jednej z następujących opcji, aby postępować zgodnie z instrukcjami w sekcji Tworzenie komunikacji równorzędnej sieci wirtualnych w artykule Samouczek: łączenie sieci wirtualnych z komunikacją równorzędną sieci wirtualnych przy użyciu witryny Azure Portal w celu komunikacji równorzędnej sieci wirtualnych i sprawdzenie, czy sieci wirtualne są połączone (z jednego końca):
Przejdź do sieci wirtualnej usługi AKS i za pomocą komunikacji równorzędnej z siecią wirtualną prywatnego punktu końcowego usługi Key Vault.
Przejdź do sieci wirtualnej prywatnego punktu końcowego usługi Key Vault i za pomocą komunikacji równorzędnej z siecią wirtualną usługi AKS.
W witrynie Azure Portal wyszukaj i wybierz nazwę innej sieci wirtualnej (sieć wirtualna, z którą wykonano komunikację równorzędną w poprzednim kroku).
W okienku nawigacji sieci wirtualnej znajdź nagłówek Ustawienia , a następnie wybierz pozycję Komunikacja równorzędna.
Na stronie komunikacji równorzędnej sieci wirtualnej sprawdź, czy kolumna Nazwa zawiera nazwę linku Komunikacja równorzędna sieci wirtualnej zdalnej określonej w kroku 2. Upewnij się również, że kolumna Stan komunikacji równorzędnej dla tego linku komunikacji równorzędnej ma wartość Połączono.
Po wykonaniu tej procedury możesz ponownie uruchomić polecenie Netcat. Rozpoznawanie nazw DNS i łączność między usługą AKS a usługą Key Vault powinny teraz zakończyć się pomyślnie. Upewnij się również, że wpisy tajne usługi Key Vault zostały pomyślnie zainstalowane i działają zgodnie z oczekiwaniami, jak pokazano w następujących danych wyjściowych:
Connection to <key-vault-name>.vault.azure.net 443 port [tcp/https] succeeded!
Rozwiązanie 4b: Rozwiązywanie problemów z kodem błędu 403
Rozwiązywanie problemów z kodem błędu "403", przeglądając sekcję HTTP 403: Niewystarczające uprawnienia w artykule Dokumentacja kodów błędów interfejsu API REST usługi Azure Key Vault.
Przyczyna 5. Brak sterownika secrets-store.csi.k8s.io na liście zarejestrowanych sterowników CSI
Jeśli zostanie wyświetlony następujący komunikat o błędzie dotyczący brakującego secrets-store.csi.k8s.io sterownika w zdarzeniach zasobnika, zasobniki sterownika CSI magazynu wpisów tajnych nie są uruchomione w węźle, w którym aplikacja jest uruchomiona:
Ostrzeżenie FailedMount 42s (x12 over 8m56s) kubelet, akswin0000000 MountVolume.SetUp nie powiodło się dla woluminu "secrets-store01-inline": kubernetes.io/csi: mounter. Nie można pobrać klienta CSI setUpAt: nie można odnaleźć nazwy sterownika secrets-store.csi.k8s.io na liście zarejestrowanych sterowników CSI
Rozwiązanie 5. Rozwiązywanie problemów z zasobnikem sterownika CSI magazynu wpisów tajnych uruchomionym w tym samym węźle
Pobierz stan zasobnika sterownika CSI magazynu wpisów tajnych uruchomionych w tym samym węźle, uruchamiając następujące polecenie:
kubectl get pod -l app=secrets-store-csi-driver -n kube-system -o wide
Jeśli stan zasobnika nie Running jest lub którykolwiek z kontenerów w tym zasobniku nie jest w Ready stanie, przejdź do sprawdzania dzienników tego zasobnika, wykonując kroki opisane w temacie Sprawdzanie dzienników zasobników magazynu wpisów tajnych i zasobników sterownika CSI.
Przyczyna 6. Nie znaleziono klasy SecretProviderClass
Podczas opisywania zasobnika aplikacji może zostać wyświetlone następujące zdarzenie:
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
To zdarzenie oznacza, że SecretProviderClass odwołanie do specyfikacji woluminu zasobnika nie istnieje w tej samej przestrzeni nazw co zasobnik aplikacji.
Rozwiązanie 6a: Tworzenie brakującego zasobu SecretProviderClass
Upewnij się, że SecretProviderClass zasób, do którego odwołuje się specyfikacja woluminu zasobnika, istnieje w tej samej przestrzeni nazw, w której działa zasobnik aplikacji.
Rozwiązanie 6b: zmodyfikuj specyfikację woluminu zasobnika aplikacji, aby odwołać się do poprawnej nazwy zasobu SecretProviderClass
Edytuj specyfikację woluminu zasobnika aplikacji, aby odwołać się do poprawnej SecretProviderClass nazwy zasobu:
...
spec:
containers:
...
volumes:
- name: my-volume
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: "xxxxxxxxx"
Przyczyna 7. Żądanie jest nieuwierzytelnione
Żądanie jest nieuwierzytelnione dla usługi Key Vault, zgodnie z kodem błędu "401".
Rozwiązanie 7. Rozwiązywanie problemów z kodem błędu 401
Rozwiązywanie problemów z kodem błędu "401", przeglądając sekcję "HTTP 401: Nieuwierzytelnione żądanie" w artykule referencyjnym dotyczącym kodów błędów interfejsu API REST usługi Azure Key Vault.
Przyczyna 8: Liczba żądań przekracza podaną wartość maksymalną
Liczba żądań przekracza podaną wartość maksymalną dla przedziału czasu, zgodnie z kodem błędu "429".
Rozwiązanie 8. Rozwiązywanie problemów z kodem błędu 429
Rozwiąż problemy z kodem błędu "429", przeglądając sekcję "HTTP 429: Zbyt wiele żądań" w artykule referencyjnym dotyczącym kodów błędów interfejsu API REST usługi Azure Key Vault.
Zastrzeżenie dotyczące innych firm
Produkty innych firm omówione w tym artykule są wytwarzane przez producentów niezależnych od firmy Microsoft. Firma Microsoft nie udziela żadnych gwarancji, dorozumianych ani żadnego innego rodzaju, w odniesieniu do wydajności lub niezawodności tych produktów.
Skontaktuj się z nami, aby uzyskać pomoc
Jeśli masz pytania lub potrzebujesz pomocy, utwórz wniosek o pomoc techniczną lub zadaj pytanie w społeczności wsparcia dla platformy Azure. Możesz również przesłać opinię o produkcie do społeczności opinii na temat platformy Azure.