Dela via


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

Azure Key Vault Secret Store-tillägget för Kubernetes ("Secret Store") 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å Secret Store skyddar dem via isolerade namnrymder 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

Tillägget Hemlig lagring 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 secret store-tillägget offline sida vid sida i ett kluster.

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

Viktigt!

Secret Store ä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 kluster som är anslutet till Azure Arc och kör 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.
  • Exemplen i den här guiden använder ett K3s-kluster .
  • 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

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.

az login
export RESOURCE_GROUP="oidc-issuer"
export LOCATION="westus2"
export AZURE_STORAGE_ACCOUNT="oidcissuer$(openssl rand -hex 4)"
export AZURE_STORAGE_CONTAINER="oidc-test"
export SUBSCRIPTION="$(az account show --query id --output tsv)"
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="azwi-kv-$(openssl rand -hex 4)"
export KEYVAULT_SECRET_NAME="my-secret"
export USER_ASSIGNED_IDENTITY_NAME="myIdentity"
az account set --subscription "${SUBSCRIPTION}"
export SERVICE_ACCOUNT_ISSUER="https://$AZURE_STORAGE_ACCOUNT.blob.core.windows.net/${AZURE_STORAGE_CONTAINER}"
export FEDERATED_IDENTITY_CREDENTIAL_NAME="myFedIdentity"
export KUBERNETES_NAMESPACE="default"
export SERVICE_ACCOUNT_NAME="workload-identity-sa"

Konfigurera en identitet för åtkomst till hemligheter

För att få åtkomst till och synkronisera en viss Azure Key Vault-hemlighet kräver Secret Store å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 via federation. Kubernetes-tjänstkontot är det du använder i en Kubernetes-podd eller annan arbetsbelastning för att få åtkomst till hemligheter från Kubernetes-hemlighetsarkivet. Secret Store-tillägget 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.

Värd för offentlig OIDC-information om ditt klusters utfärdare av tjänstkonto

Användning av federerad identitet kräver för närvarande att du konfigurerar molnlagring som värd för OIDC-formatinformation om de offentliga nycklarna i klustrets tjänstkontoutfärdare. I det här avsnittet konfigurerar du en skyddad, offentlig OIDC-utfärdar-URL (Open ID Connect) med Azure Blob Storage och laddar sedan upp ett minimalt identifieringsdokument till lagringskontot. Bakgrund finns i OIDC-konfiguration för självhanterade kluster.

  1. Skapa ett Azure Storage-konto.

    az group create --name "${RESOURCE_GROUP}" --location "${LOCATION}"
    az storage account create --resource-group "${RESOURCE_GROUP}" --name "${AZURE_STORAGE_ACCOUNT}" --allow-blob-public-access true
    az storage container create --name "${AZURE_STORAGE_CONTAINER}" --public-access blob
    

    Kommentar

    "az storage account create" kan misslyckas om azure-instansen inte har aktiverat tjänsten "Microsoft.Storage". Om du stöter på ett fel registrerar du Resursprovidern Microsoft.Storage i din prenumeration.

  2. Generera ett identifieringsdokument. Ladda upp lagringskontot och kontrollera sedan att det är offentligt tillgängligt.

    cat <<EOF > openid-configuration.json
    {
      "issuer": "https://${AZURE_STORAGE_ACCOUNT}.blob.core.windows.net/${AZURE_STORAGE_CONTAINER}/",
      "jwks_uri": "https://${AZURE_STORAGE_ACCOUNT}.blob.core.windows.net/${AZURE_STORAGE_CONTAINER}/openid/v1/jwks",
      "response_types_supported": [
        "id_token"
      ],
      "subject_types_supported": [
        "public"
      ],
      "id_token_signing_alg_values_supported": [
        "RS256"
      ]
    }
    EOF
    
    az storage blob upload --container-name "${AZURE_STORAGE_CONTAINER}" --file openid-configuration.json --name .well-known/openid-configuration
    curl -s "https://${AZURE_STORAGE_ACCOUNT}.blob.core.windows.net/${AZURE_STORAGE_CONTAINER}/.well-known/openid-configuration"
    
  3. Hämta den offentliga nyckeln för ditt klusters tjänstkonto utfärdare från dess privata nyckel. Du måste förmodligen köra det här kommandot som en superanvändare. Följande exempel är för k3s. Klustret kan lagra den privata nyckeln för utfärdaren av tjänstkontot på en annan plats.

    sudo openssl rsa -in /var/lib/rancher/k3s/server/tls/service.key -pubout -out sa.pub
    
  4. Ladda ned det senaste kommandoradsverktyget azwi, som du kan använda för att skapa ett JWKS-dokument från den offentliga nyckeln och ta bort det:

    tar -xzf <path to downloaded azwi tar.gz>
    
  5. Generera JWKS-dokumentet. Ladda upp det till lagringskontot och kontrollera sedan att det är offentligt tillgängligt.

    ./azwi jwks --public-keys sa.pub --output-file jwks.json
    az storage blob upload --container-name "${AZURE_STORAGE_CONTAINER}" --file jwks.json --name openid/v1/jwks
    curl -s "https://${AZURE_STORAGE_ACCOUNT}.blob.core.windows.net/${AZURE_STORAGE_CONTAINER}/openid/v1/jwks"
    

Konfigurera utfärdaren av klustertoken för tjänstkontot med den värdbaserade URL:en

Klustret måste också konfigureras för att utfärda tjänstkontotoken med ett utfärdar-URL-fält (service-account-issuer) som pekar på lagringskontot som du skapade i föregående avsnitt. Mer bakgrund om federationskonfigurationen finns i Klusterkonfiguration för en OIDC-utfärdare.

Du kan också konfigurera gränser för hemlighetsarkivets 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 hemlighetsarkivet kan ändra andra objekt i klustret.

Kubernetes-klustret måste köra Kubernetes version 1.27 eller senare.

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

      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 utdata från echo $SERVICE_ACCOUNT_ISSUER.

      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. Starta om kube-apiservern.

    sudo systemctl daemon-reload
    sudo systemctl restart k3s
    

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.

  1. Skapa ett Azure Key Vault:

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

  1. Skapa den användartilldelade hanterade identiteten:

    az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"
    
  2. 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.

  1. 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
    
  2. 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 och använda hemlighetsarkivet

Secret Store ä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.

Secret Store installeras som ett Azure Arc-tillägg

Installera cert-manager och trust-manager

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

  1. Installera cert-manager.

    kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.3/cert-manager.yaml
    
  2. Installera trust-manager.

    helm repo add jetstack https://charts.jetstack.io
    helm repo update
    helm upgrade trust-manager jetstack/trust-manager --install --namespace cert-manager --wait
    

Installera Azure Arc-tillägget för Secret Store

Se till att Kubernetes-klustret är anslutet till Azure Arc innan du installerar tillägget.

  1. Ange två miljövariabler för resursgruppen och namnet på det anslutna klustret. Om du följde snabbstarten som länkats tidigare är dessa "AzureArcTest" respektive "AzureArcTest1".

    export ARC_RESOURCE_GROUP="AzureArcTest"
    export ARC_CLUSTER_NAME="AzureArcTest1"
    
  2. Installera Secret Store-tillägget till ditt Arc-aktiverade kluster med följande kommando:

    az k8s-extension create \
      --cluster-name ${ARC_CLUSTER_NAME} \
      --cluster-type connectedClusters \
      --extension-type microsoft.azure.secretstore \
      --resource-group ${ARC_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 Hemlighetsarkivet kontrollerar eller uppdaterar hemligheten som den hanterar. 3600 (1 timme)

Konfigurera hemlighetsarkivet

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

Hemlighetsarkivet 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 du installerar Secret Store.

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

Secret Store ä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 secret store använder för att hantera sina hemligheter. Ta bort den befintliga etiketten och hemligheten och låt hemlighetsarkivet återskapa hemligheten: kubectl delete secret <secret-name>
Om du vill tvinga Secret Store 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 secret store använder för att hantera sina hemligheter. Ta bort den befintliga anteckningen och hemligheten och låt hemlighetsarkivet återskapa hemligheten: kubectl delete secret <secret-name>
Om du vill tvinga Secret Store 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 Secret Store kontrollerade Azure Key Vault efter uppdateringar i slutet av det konfigurerade avsökningsintervallet, men det fanns inga ändringar att synkronisera. saknas
UpdateValueChangeOrForceUpdateSucceeded Hemlighetsarkivet kontrollerade Azure Key Vault efter uppdateringar och uppdaterade värdet. saknas
UpdateFailedInvalidLabel Det gick inte att uppdatera hemligheten eftersom etiketten på hemligheten som secret store använder för att hantera sina hemligheter har ändrats. Ta bort den befintliga etiketten och hemligheten och låt hemlighetsarkivet återskapa hemligheten: kubectl delete secret <secret-name>
Om du vill tvinga Secret Store 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 secret store använder för att hantera dess hemligheter ändrades. Ta bort den befintliga anteckningen och hemligheten och låt hemlighetsarkivet återskapa hemligheten: kubectl delete secret <secret-name>
Om du vill tvinga Secret Store 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 SecretProviderClasseller 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 Secret Store 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 hemlighetsarkivet. Mer information finns i loggarna i Secret Store 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 hemlighetsarkivet eller om det uppstod problem under en uppdatering av hemlighetsarkivet. Prova att ta bort hemligheten och objektet och SecretSync låt sedan hemlighetsarkivet å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 hemlighetsarkivet

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

az k8s-extension delete --name ssarcextension --cluster-name $ARC_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