Użyj rozszerzenia Magazynu wpisów tajnych, aby pobrać wpisy tajne na potrzeby dostępu w trybie offline w klastrach Kubernetes z obsługą usługi Azure Arc
Rozszerzenie magazynu wpisów tajnych usługi Azure Key Vault dla platformy Kubernetes ("SSE") automatycznie synchronizuje wpisy tajne z usługi Azure Key Vault z klastrem Kubernetes z włączoną usługą Azure Arc w celu uzyskania dostępu w trybie offline. Oznacza to, że usługa Azure Key Vault umożliwia przechowywanie, konserwację i obracanie wpisów tajnych nawet w przypadku uruchamiania klastra Kubernetes w stanie częściowo rozłączonym. Zsynchronizowane wpisy tajne są przechowywane w magazynie wpisów tajnych klastra, udostępniając je jako wpisy tajne Kubernetes, które mają być używane na wszystkie typowe sposoby: instalowane jako woluminy danych lub udostępniane jako zmienne środowiskowe dla kontenera w zasobniku.
Zsynchronizowane wpisy tajne są krytycznymi elementami zawartości biznesowymi, dlatego SSE zabezpiecza je za pośrednictwem izolowanych przestrzeni nazw i węzłów, zasad kontroli dostępu opartej na rolach (RBAC) i ograniczonych uprawnień synchronizatora wpisów tajnych. Aby uzyskać dodatkową ochronę, zaszyfruj magazyn wpisów tajnych Kubernetes w klastrze.
Napiwek
Funkcja SSE jest zalecana w scenariuszach, w których wymagany jest dostęp w trybie offline lub jeśli potrzebujesz wpisów tajnych zsynchronizowanych z magazynem wpisów tajnych Kubernetes. Jeśli nie potrzebujesz tych funkcji, możesz użyć rozszerzenia dostawcy wpisów tajnych usługi Azure Key Vault do zarządzania wpisami tajnymi w klastrach Kubernetes z włączoną usługą Arc. Nie zaleca się uruchamiania zarówno rozszerzenia dostawcy wpisów tajnych usługi Azure Key Vault w trybie online, jak i równoległego trybu offline w klastrze.
W tym artykule pokazano, jak zainstalować i skonfigurować funkcję SSE jako rozszerzenie Kubernetes z obsługą usługi Azure Arc.
Ważne
Funkcja SSE jest obecnie dostępna w wersji zapoznawczej. Zobacz Dodatkowe warunki użytkowania wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta lub wersji zapoznawczej albo w inny sposób nie zostały jeszcze wydane jako ogólnie dostępne.
Wymagania wstępne
- Klaster z obsługą usługi Arc. Może to być taki, z którym nawiązano połączenie samodzielnie (w tym przewodniku użyto klastra K3s) lub zarządzanego przez firmę Microsoft usługi AKS objętego klastrem usługi Azure Arc. Klaster musi działać na platformie Kubernetes w wersji 1.27 lub nowszej, a w jednym z obsługiwanych regionów (Wschodnie stany USA, Wschodnie stany USA2, Zachodnie stany USA, Zachodnie stany USA 2, Zachodnie stany USA3, Europa Zachodnia, Europa Północna). Region jest definiowany przez region grupy zasobów używany do tworzenia klastra Arc.
- Upewnij się, że spełnisz ogólne wymagania wstępne dotyczące rozszerzeń klastra, w tym najnowszą wersję rozszerzenia interfejsu
k8s-extension
wiersza polecenia platformy Azure. - Menedżer certyfikatów jest wymagany do obsługi protokołu TLS na potrzeby komunikacji dzienników intracluster. Przykłady w dalszej części tego przewodnika kierują Cię przez instalację. Aby uzyskać więcej informacji na temat menedżera certyfikatów, zobacz cert-manager.io
Zainstaluj interfejs wiersza polecenia platformy Azure i zaloguj się, jeśli jeszcze tego nie zrobiono:
az login
Przed rozpoczęciem ustaw zmienne środowiskowe, które mają być używane do konfigurowania zasobów platformy Azure i klastra. Jeśli masz już tożsamość zarządzaną, usługę Azure Key Vault lub inny zasób wymieniony tutaj, zaktualizuj nazwy w zmiennych środowiskowych, aby odzwierciedlić te zasoby.
export RESOURCE_GROUP="AzureArcTest"
export CLUSTER_NAME="AzureArcTest1"
export LOCATION="EastUS"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
az account set --subscription "${SUBSCRIPTION}"
export AZURE_TENANT_ID="$(az account show -s $SUBSCRIPTION --query tenantId --output tsv)"
export CURRENT_USER="$(az ad signed-in-user show --query userPrincipalName --output tsv)"
export KEYVAULT_NAME="my-kv"
export KEYVAULT_SECRET_NAME="my-secret"
export USER_ASSIGNED_IDENTITY_NAME="my-identity"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="my-credential"
export KUBERNETES_NAMESPACE="my-namespace"
export SERVICE_ACCOUNT_NAME="my-service-account"
Aktywowanie federacji tożsamości obciążenia w klastrze
Usługa SSE używa funkcji nazywanej federacją tożsamości obciążenia w celu uzyskiwania dostępu do wpisów tajnych usługi Azure Key Vault i synchronizowania ich. W tej sekcji opisano sposób konfigurowania tego ustawienia. W poniższych sekcjach opisano szczegółowo sposób jej użycia.
- Platforma Kubernetes z obsługą usługi Arc
- Usługa AKS w środowisku lokalnym platformy Azure
- Podstawy usługi AKS Edge
Napiwek
Poniższe kroki są oparte na przewodniku z instrukcjami dotyczącymi konfigurowania platformy Kubernetes z obsługą usługi Arc z federacją tożsamości obciążenia. Zapoznaj się z dokumentacją, aby uzyskać dodatkową pomoc.
Jeśli klaster nie jest jeszcze połączony z usługą Azure Arc, wykonaj następujące kroki. Podczas tych kroków włącz federację tożsamości obciążenia w ramach connect
polecenia :
az connectedk8s connect --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --enable-oidc-issuer --enable-workload-identity
Jeśli klaster jest już połączony z usługą Azure Arc, włącz tożsamość obciążenia przy użyciu update
polecenia :
az connectedk8s update --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --enable-oidc-issuer --enable-workload-identity
Teraz skonfiguruj klaster tak, aby wystawiał tokeny konta usługi przy użyciu nowego adresu URL wystawcy (service-account-issuer
), który umożliwia identyfikatorowi entra firmy Microsoft znalezienie kluczy publicznych niezbędnych do zweryfikowania tych tokenów. Te klucze publiczne są przeznaczone dla wystawcy tokenu konta usługi klastra i zostały one uzyskane i hostowane w chmurze pod tym adresem URL w wyniku --enable-oidc-issuer
opcji ustawionej powyżej.
Opcjonalnie można również skonfigurować limity uprawnień SSE jako uprzywilejowany zasób uruchomiony na płaszczyźnie sterowania, konfigurując OwnerReferencesPermissionEnforcement
kontroler dostępu. Ten kontroler wpływu ogranicza, ile funkcja SSE może zmienić inne obiekty w klastrze.
Skonfiguruj serwer kube-apiserver przy użyciu pola adresu URL wystawcy i wymuszania uprawnień. Poniższy przykład dotyczy klastra k3s. Klaster może mieć różne sposoby zmiany argumentów serwera interfejsu API:
--kube-apiserver-arg="--service-account-issuer=${SERVICE_ACCOUNT_ISSUER}" and --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement"
.Pobierz adres URL wystawcy konta usługi.
export SERVICE_ACCOUNT_ISSUER="$(az connectedk8s show --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --query "oidcIssuerProfile.issuerUrl" --output tsv)" echo $SERVICE_ACCOUNT_ISSUER
Otwórz plik konfiguracji serwera K3s.
sudo nano /etc/systemd/system/k3s.service
Edytuj konfigurację serwera, aby wyglądała jak w poniższym przykładzie, zastępując <SERVICE_ACCOUNT_ISSUER> powyższymi danymi wyjściowymi z
echo $SERVICE_ACCOUNT_ISSUER
, pamiętając o dołączeniu końcowego ukośnika tego adresu URL:ExecStart=/usr/local/bin/k3s \ server --write-kubeconfig-mode=644 \ --kube-apiserver-arg="--service-account-issuer=<SERVICE_ACCOUNT_ISSUER>" \ --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement"
Uruchom ponownie serwer kube-apiserver.
sudo systemctl daemon-reload sudo systemctl restart k3s
Tworzenie wpisu tajnego i konfigurowanie tożsamości w celu uzyskania do niej dostępu
Aby uzyskać dostęp do danego wpisu tajnego usługi Azure Key Vault i zsynchronizować go, usługa SSE wymaga dostępu do tożsamości zarządzanej platformy Azure z odpowiednimi uprawnieniami platformy Azure w celu uzyskania dostępu do tego wpisu tajnego. Tożsamość zarządzana musi być połączona z kontem usługi Kubernetes przy użyciu funkcji tożsamości obciążenia aktywowanej powyżej. Usługa SSE używa skojarzonej federacyjnej tożsamości zarządzanej platformy Azure do ściągania wpisów tajnych z usługi Azure Key Vault do magazynu wpisów tajnych kubernetes. W poniższych sekcjach opisano sposób konfigurowania tej konfiguracji.
Tworzenie usługi Azure Key Vault
Utwórz usługę Azure Key Vault i dodaj wpis tajny. Jeśli masz już usługę Azure Key Vault i wpis tajny, możesz pominąć tę sekcję.
Tworzenie usługi Azure Key Vault:
az keyvault create --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --name "${KEYVAULT_NAME}" --enable-rbac-authorization
Nadaj sobie uprawnienia "Secrets Officer" w magazynie, aby można było utworzyć wpis tajny:
az role assignment create --role "Key Vault Secrets Officer" --assignee ${CURRENT_USER} --scope /subscriptions/${SUBSCRIPTION}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}
Utwórz wpis tajny i zaktualizuj go, aby mieć dwie wersje:
az keyvault secret set --vault-name "${KEYVAULT_NAME}" --name "${KEYVAULT_SECRET_NAME}" --value 'Hello!' az keyvault secret set --vault-name "${KEYVAULT_NAME}" --name "${KEYVAULT_SECRET_NAME}" --value 'Hello2'
Tworzenie tożsamości zarządzanej przypisanej przez użytkownika
Następnie utwórz tożsamość zarządzaną przypisaną przez użytkownika i nadaj jej uprawnienia dostępu do usługi Azure Key Vault. Jeśli masz już tożsamość zarządzaną z uprawnieniami czytelnika usługi Key Vault i użytkownika wpisów tajnych usługi Key Vault usługi Key Vault, możesz pominąć tę sekcję. Aby uzyskać więcej informacji, zobacz Create a user-assigned managed identities (Tworzenie tożsamości zarządzanych przypisanych przez użytkownika) i Using Azure RBAC secret, key and certificate permissions with Key Vault (Tworzenie tożsamości zarządzanych przypisanych przez użytkownika) i Using Azure RBAC secret, key and certificate permissions with Key Vault (Używanie wpisów tajnych, klucza i certyfikatu RBAC platformy Azure przy użyciu usługi Key Vault).
Utwórz tożsamość zarządzaną przypisaną przez użytkownika:
az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"
Nadaj tożsamości uprawnienia czytelnika usługi Key Vault i wpisów tajnych usługi Key Vault. Zanim te polecenia powiedzą się, może być konieczne odczekanie chwili na replikację tworzenia tożsamości:
export USER_ASSIGNED_CLIENT_ID="$(az identity show --resource-group "${RESOURCE_GROUP}" --name "${USER_ASSIGNED_IDENTITY_NAME}" --query 'clientId' -otsv)" az role assignment create --role "Key Vault Reader" --assignee "${USER_ASSIGNED_CLIENT_ID}" --scope /subscriptions/${SUBSCRIPTION}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME} az role assignment create --role "Key Vault Secrets User" --assignee "${USER_ASSIGNED_CLIENT_ID}" --scope /subscriptions/${SUBSCRIPTION}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}
Tworzenie poświadczeń tożsamości federacyjnej
Utwórz konto usługi Kubernetes dla obciążenia, które wymaga dostępu do wpisów tajnych. Następnie utwórz poświadczenia tożsamości federacyjnej, aby połączyć się między tożsamością zarządzaną, wystawcą konta usługi OIDC i kontem usługi Kubernetes Service.
Utwórz konto usługi Kubernetes Service, które będzie federacyjne z tożsamością zarządzaną. Dodaj do niego adnotacje ze szczegółami skojarzonej tożsamości zarządzanej przypisanej przez użytkownika.
kubectl create ns ${KUBERNETES_NAMESPACE}
cat <<EOF | kubectl apply -f - apiVersion: v1 kind: ServiceAccount metadata: name: ${SERVICE_ACCOUNT_NAME} namespace: ${KUBERNETES_NAMESPACE} EOF
Utwórz poświadczenia tożsamości federacyjnej:
az identity federated-credential create --name ${FEDERATED_IDENTITY_CREDENTIAL_NAME} --identity-name ${USER_ASSIGNED_IDENTITY_NAME} --resource-group ${RESOURCE_GROUP} --issuer ${SERVICE_ACCOUNT_ISSUER} --subject system:serviceaccount:${KUBERNETES_NAMESPACE}:${SERVICE_ACCOUNT_NAME}
Instalowanie usługi SSE
Funkcja SSE jest dostępna jako rozszerzenie usługi Azure Arc. Klaster Kubernetes z obsługą usługi Azure Arc można rozszerzyć przy użyciu rozszerzeń Kubernetes z obsługą usługi Azure Arc. Rozszerzenia umożliwiają korzystanie z możliwości platformy Azure w połączonym klastrze i zapewnienie środowiska opartego na usłudze Azure Resource Manager na potrzeby zarządzania instalacją i cyklem życia rozszerzeń.
Menedżer certyfikatów i menedżer zaufania są również wymagane do bezpiecznej komunikacji dzienników między usługami klastra i muszą być zainstalowane przed rozszerzeniem Arc.
Zainstaluj menedżera certyfikatów.
helm repo add jetstack https://charts.jetstack.io/ --force-update helm install cert-manager jetstack/cert-manager --namespace cert-manager --create-namespace --version v1.16.2 --set crds.enabled=true
Zainstaluj menedżera zaufania.
helm upgrade trust-manager jetstack/trust-manager --install --namespace cert-manager --wait
Zainstaluj usługę SSE w klastrze z obsługą usługi Arc przy użyciu następującego polecenia:
az k8s-extension create \ --cluster-name ${CLUSTER_NAME} \ --cluster-type connectedClusters \ --extension-type microsoft.azure.secretstore \ --resource-group ${RESOURCE_GROUP} \ --release-train preview \ --name ssarcextension \ --scope cluster
W razie potrzeby możesz opcjonalnie zmodyfikować domyślny interwał sondowania rotacji, dodając polecenie
--configuration-settings rotationPollIntervalInSeconds=<time_in_seconds>
:Nazwa parametru opis Domyślna wartość rotationPollIntervalInSeconds
Określa, jak szybko narzędzie SSE sprawdza lub aktualizuje wpis tajny, który zarządza. 3600
(1 godzina)
Konfigurowanie funkcji SSE
Skonfiguruj zainstalowane rozszerzenie z informacjami o usłudze Azure Key Vault i wpisami tajnymi, które mają być synchronizowane z klastrem, definiując wystąpienia zasobów niestandardowych platformy Kubernetes. Utworzysz dwa typy zasobów niestandardowych:
SecretProviderClass
Obiekt definiujące połączenie z usługą Key Vault.SecretSync
Obiekt dla każdego wpisu tajnego do synchronizacji.
Tworzenie SecretProviderClass
zasobu
Zasób SecretProviderClass
służy do definiowania połączenia z usługą Azure Key Vault, tożsamości używanej do uzyskiwania dostępu do magazynu, który ma być synchronizowany, oraz liczby wersji każdego wpisu tajnego do przechowywania lokalnego.
Dla każdej usługi Azure Key Vault, którą zamierzasz zsynchronizować, dla SecretProviderClass
każdej tożsamości używanej do uzyskiwania dostępu do usługi Azure Key Vault oraz dla każdej docelowej przestrzeni nazw kubernetes.
Utwórz co najmniej jeden SecretProviderClass
plik YAML z odpowiednimi wartościami dla usługi Key Vault i wpisów tajnych, postępując zgodnie z tym przykładem.
cat <<EOF > spc.yaml
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: secret-provider-class-name # Name of the class; must be unique per Kubernetes namespace
namespace: ${KUBERNETES_NAMESPACE} # Kubernetes namespace to make the secrets accessible in
spec:
provider: azure
parameters:
clientID: "${USER_ASSIGNED_CLIENT_ID}" # Managed Identity Client ID for accessing the Azure Key Vault with.
keyvaultName: ${KEYVAULT_NAME} # The name of the Azure Key Vault to synchronize secrets from.
objects: |
array:
- |
objectName: ${KEYVAULT_SECRET_NAME} # The name of the secret to sychronize.
objectType: secret
objectVersionHistory: 2 # [optional] The number of versions to synchronize, starting from latest.
tenantID: "${AZURE_TENANT_ID}" # The tenant ID of the Key Vault
EOF
Tworzenie SecretSync
obiektu
Każdy zsynchronizowany wpis tajny wymaga SecretSync
również obiektu , aby zdefiniować informacje specyficzne dla klastra. W tym miejscu należy określić informacje, takie jak nazwa wpisu tajnego w klastrze i nazwy dla każdej wersji wpisu tajnego przechowywanego w klastrze.
Utwórz jeden SecretSync
plik YAML obiektu dla każdego wpisu tajnego, postępując zgodnie z tym szablonem. Przestrzeń nazw kubernetes powinna być zgodna z przestrzenią nazw pasującego SecretProviderClass
elementu .
cat <<EOF > ss.yaml
apiVersion: secret-sync.x-k8s.io/v1alpha1
kind: SecretSync
metadata:
name: secret-sync-name # Name of the object; must be unique per Kubernetes namespace
namespace: ${KUBERNETES_NAMESPACE} # Kubernetes namespace
spec:
serviceAccountName: ${SERVICE_ACCOUNT_NAME} # The Kubernetes service account to be given permissions to access the secret.
secretProviderClassName: secret-provider-class-name # The name of the matching SecretProviderClass with the configuration to access the AKV storing this secret
secretObject:
type: Opaque
data:
- sourcePath: ${KEYVAULT_SECRET_NAME}/0 # Name of the secret in Azure Key Vault with an optional version number (defaults to latest)
targetKey: ${KEYVAULT_SECRET_NAME}-data-key0 # Target name of the secret in the Kubernetes secret store (must be unique)
- sourcePath: ${KEYVAULT_SECRET_NAME}/1 # [optional] Next version of the AKV secret. Note that versions of the secret must match the configured objectVersionHistory in the secrets provider class
targetKey: ${KEYVAULT_SECRET_NAME}-data-key1 # [optional] Next target name of the secret in the K8s secret store
EOF
Stosowanie adresów CRS konfiguracji
Zastosuj konfigurację zasobów niestandardowych (CRS) przy użyciu kubectl apply
polecenia :
kubectl apply -f ./spc.yaml
kubectl apply -f ./ss.yaml
Funkcja SSE automatycznie wyszukuje wpisy tajne i rozpoczyna synchronizowanie ich z klastrem.
Wyświetlanie opcji konfiguracji
Aby wyświetlić dodatkowe opcje konfiguracji dla tych dwóch niestandardowych typów zasobów, użyj kubectl describe
polecenia , aby sprawdzić rekordy CRD w klastrze:
# Get the name of any applied CRD(s)
kubectl get crds -o custom-columns=NAME:.metadata.name
# View the full configuration options and field parameters for a given CRD
kubectl describe crd secretproviderclass
kubectl describe crd secretsync
Obserwowanie synchronizacji wpisów tajnych z klastrem
Po zastosowaniu konfiguracji wpisy tajne zaczynają automatycznie synchronizować się z klastrem w określonym czasie podczas instalowania usługi SSE.
Wyświetlanie zsynchronizowanych wpisów tajnych
Wyświetl wpisy tajne zsynchronizowane z klastrem, uruchamiając następujące polecenie:
# View a list of all secrets in the namespace
kubectl get secrets -n ${KUBERNETES_NAMESPACE}
# View details of all secrets in the namespace
kubectl get secrets -n ${KUBERNETES_NAMESPACE} -o yaml
Wyświetlanie stanu ostatniej synchronizacji
Aby wyświetlić stan najnowszej synchronizacji dla danego wpisu tajnego, użyj kubectl describe
polecenia dla SecretSync
obiektu . Dane wyjściowe obejmują sygnaturę czasowa tworzenia wpisu tajnego, wersje wpisu tajnego i szczegółowe komunikaty o stanie dla każdego zdarzenia synchronizacji. Te dane wyjściowe mogą służyć do diagnozowania błędów połączenia lub konfiguracji oraz obserwowania zmian wartości wpisu tajnego.
kubectl describe secretsync secret-sync-name -n ${KUBERNETES_NAMESPACE}
Wyświetlanie wartości wpisów tajnych
Aby wyświetlić zsynchronizowane wartości wpisów tajnych, teraz przechowywane w magazynie wpisów tajnych Kubernetes, użyj następującego polecenia:
kubectl get secret secret-sync-name -n ${KUBERNETES_NAMESPACE} -o jsonpath="{.data.${KEYVAULT_SECRET_NAME}-data-key0}" | base64 -d
kubectl get secret secret-sync-name -n ${KUBERNETES_NAMESPACE} -o jsonpath="{.data.${KEYVAULT_SECRET_NAME}-data-key1}" | base64 -d
Rozwiązywanie problemów
Usługa SSE to wdrożenie platformy Kubernetes, które zawiera zasobnik z dwoma kontenerami: kontrolerem, który zarządza przechowywaniem wpisów tajnych w klastrze i dostawcą, który zarządza dostępem do usługi Azure Key Vault i ściąga z nich wpisy tajne. Każdy zsynchronizowany wpis tajny zawiera SecretSync
obiekt, który zawiera stan synchronizacji tego wpisu tajnego z usługi Azure Key Vault do magazynu wpisów tajnych klastra.
Aby rozwiązać problem, zacznij od przyjrzenia się stanowi SecretSync
obiektu zgodnie z opisem w temacie Wyświetlanie stanu ostatniej synchronizacji. W poniższej tabeli wymieniono typowe typy stanów, ich znaczenie i potencjalne kroki rozwiązywania problemów w celu rozwiązania błędów.
Typ stanu SecretSync | Szczegóły | Kroki, aby naprawić/zbadać dalej |
---|---|---|
CreateSucceeded |
Wpis tajny został pomyślnie utworzony. | nie dotyczy |
CreateFailedProviderError |
Tworzenie wpisu tajnego nie powiodło się z powodu problemu z dostawcą (połączenie z usługą Azure Key Vault). Ten błąd może być spowodowany łącznością z Internetem, niewystarczającymi uprawnieniami do synchronizowania wpisów tajnych tożsamości, błędną konfiguracją SecretProviderClass elementu lub innymi problemami. |
Zbadaj dokładniej, przeglądając dzienniki dostawcy przy użyciu następujących poleceń: kubectl get pods -n azure-secret-store kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer' |
CreateFailedInvalidLabel |
Tworzenie wpisu tajnego nie powiodło się, ponieważ wpis tajny już istnieje bez poprawnej etykiety Kubernetes używanej przez usługę SSE do zarządzania jego wpisami tajnymi. | Usuń istniejącą etykietę i wpis tajny i zezwól funkcji SSE na ponowne utworzenie wpisu tajnego: kubectl delete secret <secret-name> Aby wymusić ponowne utworzenie wpisu tajnego szybciej niż skonfigurowany interwał sondowania rotacji, usuń SecretSync obiekt (kubectl delete secretsync <secret-name> ) i ponownie zastosuj klasę synchronizacji wpisów tajnych (kubectl apply -f <path_to_secret_sync> ). |
CreateFailedInvalidAnnotation |
Tworzenie wpisu tajnego nie powiodło się, ponieważ wpis tajny już istnieje bez poprawnej adnotacji kubernetes używanej przez usługę SSE do zarządzania jego wpisami tajnymi. | Usuń istniejącą adnotację i wpis tajny i zezwól funkcji SSE na ponowne utworzenie wpisu tajnego: kubectl delete secret <secret-name> Aby wymusić ponowne utworzenie wpisu tajnego szybciej niż skonfigurowany interwał sondowania rotacji, usuń SecretSync obiekt (kubectl delete secretsync <secret-name> ) i ponownie zastosuj klasę synchronizacji wpisów tajnych (kubectl apply -f <path_to_secret_sync> ). |
UpdateNoValueChangeSucceeded |
Usługa SSE sprawdziła usługę Azure Key Vault pod kątem aktualizacji na końcu skonfigurowanego interwału sondowania, ale nie wprowadzono żadnych zmian w synchronizacji. | nie dotyczy |
UpdateValueChangeOrForceUpdateSucceeded |
Usługa SSE sprawdziła usługę Azure Key Vault pod kątem aktualizacji i pomyślnie zaktualizowała wartość. | nie dotyczy |
UpdateFailedInvalidLabel |
Aktualizacja wpisu tajnego nie powiodła się, ponieważ etykieta w wpisie tajnym używana przez usługę SSE do zarządzania jego wpisami tajnymi została zmodyfikowana. | Usuń istniejącą etykietę i wpis tajny i zezwól funkcji SSE na ponowne utworzenie wpisu tajnego: kubectl delete secret <secret-name> Aby wymusić ponowne utworzenie wpisu tajnego szybciej niż skonfigurowany interwał sondowania rotacji, usuń SecretSync obiekt (kubectl delete secretsync <secret-name> ) i ponownie zastosuj klasę synchronizacji wpisów tajnych (kubectl apply -f <path_to_secret_sync> ). |
UpdateFailedInvalidAnnotation |
Aktualizacja wpisu tajnego nie powiodła się, ponieważ adnotacja wpisu tajnego używana przez usługę SSE do zarządzania jego wpisami tajnymi została zmodyfikowana. | Usuń istniejącą adnotację i wpis tajny i zezwól funkcji SSE na ponowne utworzenie wpisu tajnego: kubectl delete secret <secret-name> Aby wymusić ponowne utworzenie wpisu tajnego szybciej niż skonfigurowany interwał sondowania rotacji, usuń SecretSync obiekt (kubectl delete secretsync <secret-name> ) i ponownie zastosuj klasę synchronizacji wpisów tajnych (kubectl apply -f <path_to_secret_sync> ). |
UpdateFailedProviderError |
Aktualizacja wpisu tajnego nie powiodła się z powodu problemu z dostawcą (połączenie z usługą Azure Key Vault). Ten błąd może być spowodowany łącznością z Internetem, niewystarczającymi uprawnieniami do synchronizowania tożsamości wpisów tajnych, konfiguracją SecretProviderClass programu lub innymi problemami. |
Zbadaj dokładniej, przeglądając dzienniki dostawcy przy użyciu następujących poleceń: kubectl get pods -n azure-secret-store kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer' |
UserInputValidationFailed |
Aktualizacja wpisu tajnego nie powiodła się, ponieważ klasa synchronizacji wpisów tajnych została niepoprawnie skonfigurowana (na przykład nieprawidłowy typ wpisu tajnego). | Przejrzyj definicję klasy synchronizacji wpisów tajnych i popraw wszelkie błędy. Następnie usuń obiekt (), usuń klasę SecretSync synchronizacji wpisów tajnych (kubectl delete secretsync <secret-name> kubectl delete -f <path_to_secret_sync> ) i ponownie zastosuj klasę synchronizacji wpisów tajnych (kubectl apply -f <path_to_secret_sync> ). |
ControllerSpcError |
Aktualizacja wpisu tajnego nie powiodła się, ponieważ usługa SSE nie może pobrać klasy dostawcy lub klasa dostawcy jest nieprawidłowo skonfigurowana. | Przejrzyj klasę dostawcy i popraw wszelkie błędy. Następnie usuń obiekt (), usuń klasę SecretSync dostawcy (kubectl delete secretsync <secret-name> kubectl delete -f <path_to_provider> ) i ponownie zastosuj klasę dostawcy (kubectl apply -f <path_to_provider> ). |
ControllerInternalError |
Aktualizacja wpisu tajnego nie powiodła się z powodu błędu wewnętrznego w funkcji SSE. | Aby uzyskać więcej informacji, sprawdź dzienniki SSE lub zdarzenia: kubectl get pods -n azure-secret-store kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='manager' |
SecretPatchFailedUnknownError |
Aktualizacja wpisu tajnego nie powiodła się podczas stosowania poprawek wartości wpisu tajnego platformy Kubernetes. Ten błąd może wystąpić, jeśli wpis tajny został zmodyfikowany przez inną osobę niż SSE lub jeśli wystąpiły problemy podczas aktualizacji SSE. | Spróbuj usunąć wpis tajny i SecretSync obiekt, a następnie pozwól usłudze SSE ponownie utworzyć wpis tajny, ponownie stosując synchronizację wpisu tajnego CR: kubectl delete secret <secret-name> kubectl delete secretsync <secret-name> kubectl apply -f <path_to_secret_sync> |
Usuwanie funkcji SSE
Aby usunąć SSE i zatrzymać synchronizowanie wpisów tajnych, odinstaluj je za az k8s-extension delete
pomocą polecenia :
az k8s-extension delete --name ssarcextension --cluster-name $CLUSTER_NAME --resource-group $RESOURCE_GROUP --cluster-type connectedClusters
Odinstalowanie rozszerzenia nie powoduje usunięcia wpisów tajnych, SecretSync
obiektów ani identyfikatorów CRD z klastra. Te obiekty muszą zostać usunięte bezpośrednio za pomocą polecenia kubectl
.
Usunięcie funkcji SecretSync CRD powoduje usunięcie wszystkich SecretSync
obiektów, a domyślnie usuwa wszystkie należące do niego wpisy tajne, ale wpisy tajne mogą być utrwalane w następujących przypadkach:
- Zmodyfikowano własność dowolnych wpisów tajnych.
- Zmieniono ustawienia odzyskiwania pamięci w klastrze, w tym ustawienie różnych finalizatorów.
W powyższych przypadkach wpisy tajne muszą zostać usunięte bezpośrednio przy użyciu polecenia kubectl
.
Następne kroki
- Dowiedz się więcej o rozszerzeniach usługi Azure Arc.
- Dowiedz się więcej o usłudze Azure Key Vault.