Udostępnij za pośrednictwem


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.

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.

  1. 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"
      
  2. 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ę.

  1. Tworzenie usługi Azure Key Vault:

    az keyvault create --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --name "${KEYVAULT_NAME}" --enable-rbac-authorization
    
  2. 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}
    
  3. 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).

  1. 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}"
    
  2. 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.

  1. 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
    
  2. 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.

  1. 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 
    
  2. Zainstaluj menedżera zaufania.

    helm upgrade trust-manager jetstack/trust-manager --install --namespace cert-manager --wait
    
  3. 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 SecretProviderClasselementu .

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ą SecretProviderClasselementu 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ą SecretProviderClassprogramu 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:

W powyższych przypadkach wpisy tajne muszą zostać usunięte bezpośrednio przy użyciu polecenia kubectl.

Następne kroki