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.
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.
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"
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
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>
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.
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"
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.
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 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.
Installera cert-manager.
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.3/cert-manager.yaml
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.
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"
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 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 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
- Läs mer om Azure Arc-tillägg.
- Läs mer om Azure Key Vault.