Använd tillägget Secret Store för att hämta hemligheter för offlineåtkomst i Azure Arc-aktiverade Kubernetes-kluster

Artikel
12/11/2024

Azure Key Vault Secret Store-tillägget för Kubernetes ("SSE") synkroniserar automatiskt hemligheter från ett Azure Key Vault till ett Azure Arc-aktiverat Kubernetes-kluster för offlineåtkomst. Det innebär att du kan använda Azure Key Vault för att lagra, underhålla och rotera dina hemligheter, även när du kör Kubernetes-klustret i ett semi-frånkopplat tillstånd. Synkroniserade hemligheter lagras i klusterhemlighetslagret, vilket gör dem tillgängliga som Kubernetes-hemligheter som ska användas på alla vanliga sätt: monterade som datavolymer eller exponerade som miljövariabler till en container i en podd.

Synkroniserade hemligheter är viktiga affärstillgångar, så SSE skyddar dem genom isolerade namnområden och noder, rollbaserade åtkomstkontrollprinciper (RBAC) och begränsade behörigheter för synkroniseringen av hemligheter. För extra skydd krypterar du Kubernetes-hemlighetsarkivet i klustret.

Dricks

Handelshögskolan rekommenderas för scenarier där offlineåtkomst krävs, eller om du behöver hemligheter synkroniserade med Kubernetes-hemlighetsarkivet. Om du inte behöver de här funktionerna kan du använda tillägget Azure Key Vault Secrets Provider för hemlig hantering i dina Arc-aktiverade Kubernetes-kluster. Vi rekommenderar inte att du kör både azure Key Vault Secrets Provider-tillägget online och offline-SSE sida vid sida i ett kluster.

Den här artikeln visar hur du installerar och konfigurerar SSE som ett Azure Arc-aktiverat Kubernetes-tillägg.

Viktigt!

SSE är för närvarande i förhandsversion. Juridiska villkor för Azure-funktioner i betaversion, förhandsversion eller som av någon annan anledning inte har gjorts allmänt tillgängliga ännu finns i kompletterande användningsvillkor för Microsoft Azure-förhandsversioner.

Förutsättningar

Ett Arc-aktiverat kluster. Detta kan vara ett som du har anslutit till dig själv (exemplen i den här guiden använder ett K3s-kluster ) eller ett Microsoft-hanterat AKS som kan användas av Azure Arc-kluster . Klustret måste köra Kubernetes version 1.27 eller senare och i en av de regioner som stöds (USA, östra, USA, östra 2, USA, västra, USA, västra 2, USA, västra3, Europa, västra, Europa, norra). Regionen definieras av den resursgruppsregion som används för att skapa Arc-klustret.
Se till att du uppfyller de allmänna förutsättningarna för klustertillägg, inklusive den senaste versionen av k8s-extension Azure CLI-tillägget.
cert-manager krävs för att stödja TLS för intracluster-loggkommunikation. Exemplen senare i den här guiden leder dig genom installationen. Mer information om cert-manager finns i cert-manager.io

Installera Azure CLI och logga in, om du inte redan har gjort det:

az login

Innan du börjar anger du miljövariabler som ska användas för att konfigurera Azure- och klusterresurser. Om du redan har en hanterad identitet, Azure Key Vault eller någon annan resurs som anges här uppdaterar du namnen i miljövariablerna så att de återspeglar dessa resurser.

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"

Aktivera identitetsfederation för arbetsbelastning i klustret

SSE använder en funktion som kallas arbetsbelastningsidentitetsfederation för att komma åt och synkronisera Azure Key Vault-hemligheter. I det här avsnittet beskrivs hur du konfigurerar detta. I följande avsnitt förklaras hur det används i detalj.

Dricks

Följande steg baseras på instruktionsguiden för att konfigurera Arc-aktiverade Kubernetes med arbetsbelastningsidentitetsfederation. Mer hjälp finns i dokumentationen.

Om klustret ännu inte är anslutet till Azure Arc följer du dessa steg. Under de här stegen aktiverar du arbetsbelastningsidentitetsfederation som en del av connect kommandot:

az connectedk8s connect --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --enable-oidc-issuer

Om klustret redan är anslutet till Azure Arc aktiverar du arbetsbelastningsidentiteten update med kommandot :

az connectedk8s update --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --enable-oidc-issuer

Konfigurera nu klustret för att utfärda tjänstkontotoken med en ny utfärdar-URL (service-account-issuer) som gör det möjligt för Microsoft Entra-ID att hitta de offentliga nycklar som krävs för att verifiera dessa token. Dessa offentliga nycklar är till för klustrets egen utfärdare av tjänstkontotoken, och de hämtades och finns i molnet på den här URL:en som ett resultat av --enable-oidc-issuer det alternativ som du angav ovan.

Du kan också konfigurera gränser för handelshögskolans egna behörigheter som en privilegierad resurs som körs i kontrollplanet genom att OwnerReferencesPermissionEnforcement konfigurera antagningskontrollanten. Den här antagningskontrollanten begränsar hur mycket SSE kan ändra andra objekt i klustret.

Konfigurera kube-apiservern med utfärdarens URL-fält och behörighetsframtvingande. Följande exempel är för ett k3s-kluster. Klustret kan ha olika sätt att ändra API-serverargument: --kube-apiserver-arg="--service-account-issuer=${SERVICE_ACCOUNT_ISSUER}" and --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement".
- Hämta url:en för utfärdaren av tjänstkontot.
```
export SERVICE_ACCOUNT_ISSUER="$(az connectedk8s show --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --query "oidcIssuerProfile.issuerUrl" --output tsv)"
echo $SERVICE_ACCOUNT_ISSUER
```
- Öppna konfigurationsfilen för K3s-servern.
```
sudo nano /etc/systemd/system/k3s.service
```
- Redigera serverkonfigurationen så att den ser ut som i följande exempel och ersätt <SERVICE_ACCOUNT_ISSUER> med ovanstående utdata från echo $SERVICE_ACCOUNT_ISSUERoch kom ihåg att inkludera det avslutande snedstrecket för den här URL:en:
```
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"
```

Starta om kube-apiservern.

sudo systemctl daemon-reload
sudo systemctl restart k3s

Använd instruktionsguiden för att aktivera arbetsbelastningsidentitetsfederation på AKS på Azure Local med hjälp --enable-oidc-issuer av flaggan.

Gå tillbaka till de här stegen efter den första aktiveringen. Resten av den guiden behöver inte slutföras.

Verifiera att aktiveringen har lyckats genom att hämta klustrets url för tjänstkonto utfärdare. Du använder den här URL:en i följande steg:

export SERVICE_ACCOUNT_ISSUER="$(az connectedk8s show --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --query "oidcIssuerProfile.issuerUrl" --output tsv)"
echo $SERVICE_ACCOUNT_ISSUER

Använd instruktionsguiden för att aktivera arbetsbelastningsidentitetsfederation på AKS Edge Essentials.

Gå tillbaka till de här stegen efter den första aktiveringen. Resten av den guiden behöver inte slutföras.

Verifiera att aktiveringen har lyckats genom att hämta klustrets url för tjänstkonto utfärdare. Du använder den här URL:en i följande steg:

export SERVICE_ACCOUNT_ISSUER="$(az connectedk8s show --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --query "oidcIssuerProfile.issuerUrl" --output tsv)"
echo $SERVICE_ACCOUNT_ISSUER

Skapa en hemlighet och konfigurera en identitet för åtkomst till den

För att få åtkomst till och synkronisera en viss Azure Key Vault-hemlighet kräver SSE åtkomst till en Hanterad Azure-identitet med lämpliga Azure-behörigheter för att få åtkomst till den hemligheten. Den hanterade identiteten måste vara länkad till ett Kubernetes-tjänstkonto med hjälp av den arbetsbelastningsidentitetsfunktion som du aktiverade ovan. Handelshögskolan använder den associerade federerade hanterade Azure-identiteten för att hämta hemligheter från Azure Key Vault till ditt Kubernetes-hemlighetsarkiv. I följande avsnitt beskrivs hur du konfigurerar detta.

Skapa ett Azure Key Vault

Skapa ett Azure Key Vault och lägg till en hemlighet. Om du redan har ett Azure Key Vault och en hemlighet kan du hoppa över det här avsnittet.

Skapa ett Azure Key Vault:

az keyvault create --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --name "${KEYVAULT_NAME}" --enable-rbac-authorization

Ge dig själv behörigheter för "Secrets Officer" i valvet så att du kan skapa en hemlighet:

az role assignment create --role "Key Vault Secrets Officer" --assignee ${CURRENT_USER} --scope /subscriptions/${SUBSCRIPTION}/resourcegroups/${RESOURCE_GROUP}/providers/Microsoft.KeyVault/vaults/${KEYVAULT_NAME}

Skapa en hemlighet och uppdatera den så att du har två versioner:

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'

Skapa en användartilldelad hanterad identitet

Skapa sedan en användartilldelad hanterad identitet och ge den behörighet att komma åt Azure Key Vault. Om du redan har en hanterad identitet med behörigheten Key Vault Reader och Key Vault Secrets User till Azure Key Vault kan du hoppa över det här avsnittet. Mer information finns i Skapa en användartilldelad hanterad identitet och Använda Azure RBAC-hemlighet, nyckel- och certifikatbehörigheter med Key Vault.

Skapa den användartilldelade hanterade identiteten:

az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"

Ge identiteten Key Vault Reader och Key Vault Secrets User behörigheter. Du kan behöva vänta en stund på replikering av identitetsskapandet innan dessa kommandon lyckas:

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}

Skapa en federerad identitetsautentiseringsuppgift

Skapa ett Kubernetes-tjänstkonto för den arbetsbelastning som behöver åtkomst till hemligheter. Skapa sedan en federerad identitetsautentiseringsuppgift för att länka mellan den hanterade identiteten, utfärdaren av OIDC-tjänstkontot och Kubernetes-tjänstkontot.

Skapa ett Kubernetes-tjänstkonto som federeras till den hanterade identiteten. Kommentera den med information om den associerade användartilldelade hanterade identiteten.

kubectl create ns ${KUBERNETES_NAMESPACE}

cat <<EOF | kubectl apply -f -
  apiVersion: v1
  kind: ServiceAccount
  metadata:
    name: ${SERVICE_ACCOUNT_NAME}
    namespace: ${KUBERNETES_NAMESPACE}
EOF

Skapa en federerad identitetsautentiseringsuppgift:

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}

Installera SSE

SSE är tillgängligt som ett Azure Arc-tillägg. Ett Azure Arc-aktiverat Kubernetes-kluster kan utökas med Azure Arc-aktiverade Kubernetes-tillägg. Tillägg möjliggör Azure-funktioner i ditt anslutna kluster och ger en Azure Resource Manager-driven upplevelse för tilläggsinstallation och livscykelhantering.

cert-manager och trust-manager krävs också för säker kommunikation av loggar mellan klustertjänster och måste installeras före Arc-tillägget.

Installera cert-manager.

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

Installera trust-manager.

helm upgrade trust-manager jetstack/trust-manager --install --namespace cert-manager --wait

Installera SSE till ditt Arc-aktiverade kluster med följande kommando:
```
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 
```
Om du vill kan du ändra standardintervallet för rotationssökning genom att lägga till --configuration-settings rotationPollIntervalInSeconds=<time_in_seconds>:

Parameternamn beskrivning Standardvärde

rotationPollIntervalInSeconds Anger hur snabbt SSE kontrollerar eller uppdaterar hemligheten som den hanterar. 3600 (1 timme)

Parameternamn	beskrivning	Standardvärde
`rotationPollIntervalInSeconds`	Anger hur snabbt SSE kontrollerar eller uppdaterar hemligheten som den hanterar.	`3600` (1 timme)

Konfigurera SSE

Konfigurera det installerade tillägget med information om ditt Azure Key Vault och vilka hemligheter som ska synkroniseras med klustret genom att definiera instanser av anpassade Kubernetes-resurser. Du skapar två typer av anpassade resurser:

Ett SecretProviderClass objekt som definierar anslutningen till Key Vault.
Ett SecretSync objekt för varje hemlighet som ska synkroniseras.

Skapa en `SecretProviderClass` resurs

Resursen SecretProviderClass används för att definiera anslutningen till Azure Key Vault, identiteten som ska användas för att komma åt valvet, vilka hemligheter som ska synkroniseras och antalet versioner av varje hemlighet som ska behållas lokalt.

Du behöver en separat SecretProviderClass för varje Azure Key Vault som du tänker synkronisera, för varje identitet som används för åtkomst till ett Azure Key Vault och för varje Kubernetes-målnamnområde.

Skapa en eller flera SecretProviderClass YAML-filer med lämpliga värden för ditt Key Vault och dina hemligheter genom att följa det här exemplet.

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

Skapa ett `SecretSync` objekt

Varje synkroniserad hemlighet kräver också ett SecretSync objekt för att definiera klusterspecifik information. Här anger du information, till exempel namnet på hemligheten i klustret och namn för varje version av hemligheten som lagras i klustret.

Skapa en SecretSync YAML-objektfil för varje hemlighet enligt den här mallen. Kubernetes-namnområdet ska matcha namnområdet för matchande SecretProviderClass.

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

Tillämpa konfigurations-CR:erna

Använd de anpassade konfigurationsresurserna (CR) med kommandot kubectl apply :

kubectl apply -f ./spc.yaml
kubectl apply -f ./ss.yaml

SSE söker automatiskt efter hemligheterna och börjar synkronisera dem till klustret.

Visa konfigurationsalternativ

Om du vill visa ytterligare konfigurationsalternativ för dessa två anpassade resurstyper använder du kubectl describe kommandot för att granska CRD:erna i klustret:

# 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

Observera hemligheter som synkroniseras med klustret

När konfigurationen har tillämpats börjar hemligheter synkroniseras automatiskt med klustret vid den takt som anges när SSE installeras.

Visa synkroniserade hemligheter

Visa hemligheterna som synkroniserats med klustret genom att köra följande kommando:

# 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

Visa senaste synkroniseringsstatus

Om du vill visa status för den senaste synkroniseringen för en viss hemlighet använder du kubectl describe kommandot för SecretSync objektet. Utdata innehåller tidsstämpeln för att skapa hemligheter, versionerna av hemligheten och detaljerade statusmeddelanden för varje synkroniseringshändelse. Dessa utdata kan användas för att diagnostisera anslutnings- eller konfigurationsfel och för att se när det hemliga värdet ändras.

kubectl describe secretsync secret-sync-name -n ${KUBERNETES_NAMESPACE}

Visa hemligheters värden

Om du vill visa de synkroniserade hemliga värdena, som nu lagras i Kubernetes hemliga arkiv, använder du följande kommando:

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

Felsökning

SSE är en Kubernetes-distribution som innehåller en podd med två containrar: kontrollanten, som hanterar lagring av hemligheter i klustret, och providern, som hanterar åtkomst till och hämtar hemligheter från Azure Key Vault. Varje synkroniserad hemlighet har ett SecretSync objekt som innehåller status för synkroniseringen av hemligheten från Azure Key Vault till klusterhemlighetsarkivet.

Om du vill felsöka ett problem börjar du med att titta på objektets tillstånd enligt beskrivningen SecretSync i Visa senaste synkroniseringsstatus. I följande tabell visas vanliga statustyper, deras betydelser och potentiella felsökningssteg för att lösa fel.

Statustyp för SecretSync	Details	Steg för att åtgärda/undersöka ytterligare
`CreateSucceeded`	Hemligheten har skapats.	saknas
`CreateFailedProviderError`	Det gick inte att skapa hemligheten på grund av ett problem med providern (anslutning till Azure Key Vault). Det här felet kan bero på internetanslutning, otillräcklig behörighet för identitetssynkroniseringshemligheter, felkonfiguration av `SecretProviderClass`, eller andra problem.	Undersök ytterligare genom att titta på loggarna för providern med hjälp av följande kommandon: `kubectl get pods -n azure-secret-store` `kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'`
`CreateFailedInvalidLabel`	Det gick inte att skapa hemligheten eftersom hemligheten redan finns utan rätt Kubernetes-etikett som SSE använder för att hantera sina hemligheter.	Ta bort den befintliga etiketten och hemligheten och låt SSE återskapa hemligheten: `kubectl delete secret <secret-name>` Om du vill tvinga SSE att återskapa hemligheten snabbare än det konfigurerade rotationsmätningsintervallet `SecretSync` tar du bort objektet (`kubectl delete secretsync <secret-name>`) och använder den hemliga synkroniseringsklassen igen (`kubectl apply -f <path_to_secret_sync>`).
`CreateFailedInvalidAnnotation`	Det gick inte att skapa hemligheten eftersom hemligheten redan finns utan rätt Kubernetes-anteckning som SSE använder för att hantera sina hemligheter.	Ta bort den befintliga anteckningen och hemligheten och låt SSE återskapa hemligheten: `kubectl delete secret <secret-name>` Om du vill tvinga SSE att återskapa hemligheten snabbare än det konfigurerade rotationsmätningsintervallet `SecretSync` tar du bort objektet (`kubectl delete secretsync <secret-name>`) och använder den hemliga synkroniseringsklassen igen (`kubectl apply -f <path_to_secret_sync>`).
`UpdateNoValueChangeSucceeded`	SSE kontrollerade Azure Key Vault efter uppdateringar i slutet av det konfigurerade avsökningsintervallet, men det fanns inga ändringar att synkronisera.	saknas
`UpdateValueChangeOrForceUpdateSucceeded`	Handelshögskolan kontrollerade Azure Key Vault efter uppdateringar och uppdaterade värdet.	saknas
`UpdateFailedInvalidLabel`	Det gick inte att uppdatera hemligheten eftersom etiketten på hemligheten som SSE använder för att hantera sina hemligheter ändrades.	Ta bort den befintliga etiketten och hemligheten och låt SSE återskapa hemligheten: `kubectl delete secret <secret-name>` Om du vill tvinga SSE att återskapa hemligheten snabbare än det konfigurerade rotationsmätningsintervallet `SecretSync` tar du bort objektet (`kubectl delete secretsync <secret-name>`) och använder den hemliga synkroniseringsklassen igen (`kubectl apply -f <path_to_secret_sync>`).
`UpdateFailedInvalidAnnotation`	Det gick inte att uppdatera hemligheten eftersom anteckningen om hemligheten som SSE använder för att hantera sina hemligheter ändrades.	Ta bort den befintliga anteckningen och hemligheten och låt SSE återskapa hemligheten: `kubectl delete secret <secret-name>` Om du vill tvinga SSE att återskapa hemligheten snabbare än det konfigurerade rotationsmätningsintervallet `SecretSync` tar du bort objektet (`kubectl delete secretsync <secret-name>`) och använder den hemliga synkroniseringsklassen igen (`kubectl apply -f <path_to_secret_sync>`).
`UpdateFailedProviderError`	Det gick inte att uppdatera hemligheten på grund av ett problem med providern (anslutning till Azure Key Vault). Det här felet kan bero på Internetanslutning, otillräcklig behörighet för identitetssynkroniseringshemligheter, konfiguration av `SecretProviderClass`eller andra problem.	Undersök ytterligare genom att titta på loggarna för providern med hjälp av följande kommandon: `kubectl get pods -n azure-secret-store` `kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'`
`UserInputValidationFailed`	Det gick inte att uppdatera hemligheten eftersom klassen för hemlig synkronisering har konfigurerats felaktigt (till exempel en ogiltig hemlig typ).	Granska definitionen av klassen secret sync och korrigera eventuella fel. Ta sedan bort `SecretSync` objektet (`kubectl delete secretsync <secret-name>`), ta bort den hemliga synkroniseringsklassen (`kubectl delete -f <path_to_secret_sync>`) och använd sedan klassen för hemlig synkronisering igen (`kubectl apply -f <path_to_secret_sync>`).
`ControllerSpcError`	Det gick inte att uppdatera hemligheten eftersom SSE inte kunde hämta providerklassen eller så är providerklassen felkonfigurerad.	Granska providerklassen och korrigera eventuella fel. Ta sedan bort `SecretSync` objektet (`kubectl delete secretsync <secret-name>`), ta bort providerklassen (`kubectl delete -f <path_to_provider>`) och använd providerklassen igen (`kubectl apply -f <path_to_provider>`).
`ControllerInternalError`	Det gick inte att uppdatera hemligheten på grund av ett internt fel i handelshögskolan.	Mer information finns i SSE-loggarna eller händelserna: `kubectl get pods -n azure-secret-store` `kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='manager'`
`SecretPatchFailedUnknownError`	Det gick inte att uppdatera hemligheten under korrigeringen av kubernetes-hemlighetsvärdet. Det här felet kan inträffa om hemligheten har ändrats av någon annan än Handelshögskolan eller om det uppstod problem under en uppdatering av handelshögskolan.	Prova att ta bort hemligheten och objektet och `SecretSync` låt sedan SSE återskapa hemligheten genom att använda cr:en för hemlig synkronisering igen: `kubectl delete secret <secret-name>` `kubectl delete secretsync <secret-name>` `kubectl apply -f <path_to_secret_sync>`

Ta bort handelshögskolan

Om du vill ta bort SSE och sluta synkronisera hemligheter avinstallerar du den med az k8s-extension delete kommandot :

az k8s-extension delete --name ssarcextension --cluster-name $CLUSTER_NAME  --resource-group $RESOURCE_GROUP  --cluster-type connectedClusters

Om du avinstallerar tillägget tas inte hemligheter, SecretSync objekt eller CRD:er bort från klustret. Dessa objekt måste tas bort direkt med kubectl.

Om du tar bort SecretSync CRD tas alla SecretSync objekt bort och alla ägda hemligheter tas bort som standard, men hemligheter kan sparas om:

Du har ändrat ägarskapet för någon av hemligheterna.
Du har ändrat inställningarna för skräpinsamling i klustret, inklusive att ange olika finalizers.

I ovanstående fall måste hemligheter tas bort direkt med hjälp av kubectl.

Nästa steg

Läs mer om Azure Arc-tillägg.
Läs mer om Azure Key Vault.

Dela via

Använd tillägget Secret Store för att hämta hemligheter för offlineåtkomst i Azure Arc-aktiverade Kubernetes-kluster

Förutsättningar

Aktivera identitetsfederation för arbetsbelastning i klustret

Skapa en hemlighet och konfigurera en identitet för åtkomst till den

Skapa ett Azure Key Vault

Skapa en användartilldelad hanterad identitet

Skapa en federerad identitetsautentiseringsuppgift

Installera SSE

Konfigurera SSE

Skapa en `SecretProviderClass` resurs

Skapa ett `SecretSync` objekt

Tillämpa konfigurations-CR:erna

Visa konfigurationsalternativ

Observera hemligheter som synkroniseras med klustret

Visa synkroniserade hemligheter

Visa senaste synkroniseringsstatus

Visa hemligheters värden

Felsökning

Ta bort handelshögskolan

Nästa steg

Feedback

Ytterligare resurser

Dela via

Använd tillägget Secret Store för att hämta hemligheter för offlineåtkomst i Azure Arc-aktiverade Kubernetes-kluster

Förutsättningar

Aktivera identitetsfederation för arbetsbelastning i klustret

Skapa en hemlighet och konfigurera en identitet för åtkomst till den

Skapa ett Azure Key Vault

Skapa en användartilldelad hanterad identitet

Skapa en federerad identitetsautentiseringsuppgift

Installera SSE

Konfigurera SSE

Skapa en SecretProviderClass resurs

Skapa ett SecretSync objekt

Tillämpa konfigurations-CR:erna

Visa konfigurationsalternativ

Observera hemligheter som synkroniseras med klustret

Visa synkroniserade hemligheter

Visa senaste synkroniseringsstatus

Visa hemligheters värden

Felsökning

Ta bort handelshögskolan

Nästa steg

Feedback

Ytterligare resurser

Skapa en `SecretProviderClass` resurs

Skapa ett `SecretSync` objekt