Delen via

De secret store-extensie gebruiken om geheimen op te halen voor offlinetoegang in Kubernetes-clusters met Azure Arc

  • Artikel

De Azure Key Vault Secret Store-extensie voor Kubernetes ('SSE') synchroniseert automatisch geheimen van een Azure Key Vault naar een Kubernetes-cluster met Azure Arc voor offlinetoegang. Dit betekent dat u Azure Key Vault kunt gebruiken om uw geheimen op te slaan, te onderhouden en te roteren, zelfs wanneer u uw Kubernetes-cluster in een semi-verbroken status uitvoert. Gesynchroniseerde geheimen worden opgeslagen in het clustergeheimarchief, waardoor ze beschikbaar worden gemaakt als Kubernetes-geheimen die op alle gebruikelijke manieren moeten worden gebruikt: gekoppeld als gegevensvolumes of worden weergegeven als omgevingsvariabelen voor een container in een pod.

Gesynchroniseerde geheimen zijn essentiële zakelijke assets, dus de SSE beveiligt deze via geïsoleerde naamruimten en knooppunten, op rollen gebaseerd toegangsbeheerbeleid (RBAC) en beperkte machtigingen voor de geheimensynchronisatieroutine. Versleutel voor extra beveiliging het Kubernetes-geheimarchief op uw cluster.

Tip

De SSE wordt aanbevolen voor scenario's waarin offlinetoegang nodig is, of als u geheimen wilt synchroniseren met het Kubernetes-geheimarchief. Als u deze functies niet nodig hebt, kunt u de Azure Key Vault Secrets Provider-extensie gebruiken voor geheimbeheer in uw Kubernetes-clusters met Arc. Het wordt niet aanbevolen om zowel de online Azure Key Vault Secrets Provider-extensie als de offline-SSE naast elkaar in een cluster uit te voeren.

In dit artikel leest u hoe u de SSE installeert en configureert als een Kubernetes-extensie met Azure Arc.

Belangrijk

SSE is momenteel beschikbaar als PREVIEW-versie. Raadpleeg de Aanvullende voorwaarden voor Microsoft Azure-previews voor juridische voorwaarden die van toepassing zijn op Azure-functies die in bèta of preview zijn of die anders nog niet algemeen beschikbaar zijn.

Vereisten

  • Een cluster dat is verbonden met Azure Arc, waarop Kubernetes versie 1.27 of hoger wordt uitgevoerd en in een van de ondersteunde regio's (VS - oost, VS - oost2, VS - west, VS - west2, VS - west3, Europa - west, Europa - noord). De regio wordt gedefinieerd door de resourcegroepregio die wordt gebruikt voor het maken van het Arc-cluster.
  • In de voorbeelden in deze handleiding wordt een K3s-cluster gebruikt.
  • Zorg ervoor dat u voldoet aan de algemene vereisten voor clusterextensies, inclusief de nieuwste versie van de k8s-extension Azure CLI-extensie.
  • Certificaatbeheer is vereist om TLS te ondersteunen voor intraclusterlogboekcommunicatie. In de voorbeelden verderop in deze handleiding wordt u door de installatie geleid. Zie cert-manager.io voor meer informatie over certificaatbeheer

Installeer de Azure CLI en meld u aan als u dat nog niet hebt gedaan:

az login

Voordat u begint, stelt u omgevingsvariabelen in die moeten worden gebruikt voor het configureren van Azure- en clusterbronnen. Als u al een beheerde identiteit, Azure Key Vault of een andere resource hebt die hier wordt vermeld, werkt u de namen in de omgevingsvariabelen bij om deze resources weer te geven.

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"

Een identiteit configureren voor toegang tot geheimen

Voor toegang tot en synchronisatie van een bepaald Azure Key Vault-geheim heeft de SSE toegang nodig tot een door Azure beheerde identiteit met de juiste Azure-machtigingen voor toegang tot dat geheim. De beheerde identiteit moet worden gekoppeld aan een Kubernetes-serviceaccount via federatie van workloadidentiteit. Het Kubernetes-serviceaccount is wat u gebruikt in een Kubernetes-pod of een andere workload voor toegang tot geheimen uit het Kubernetes-geheime archief. De SSE maakt gebruik van de gekoppelde federatieve, door Azure beheerde identiteit om geheimen uit Azure Key Vault op te halen naar uw Kubernetes-geheimarchief. In de volgende secties wordt beschreven hoe u dit instelt.

Workloadidentiteit inschakelen in uw cluster

Als uw cluster nog niet is verbonden met Azure Arc, volgt u deze stappen. Schakel tijdens deze stappen de workloadidentiteit in als onderdeel van de connect opdracht:

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

Als uw cluster al is verbonden met Azure Arc, schakelt u de workloadidentiteit in met behulp van de update opdracht:

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

Uw cluster configureren om tokenvalidatie in te schakelen

Uw cluster moet zijn geconfigureerd om serviceaccounttokens uit te geven met een nieuwe URL voor verleners (service-account-issuer) waarmee Microsoft Entra ID de openbare sleutels kan vinden die nodig zijn om deze tokens te valideren. Deze openbare sleutels zijn voor de tokenverlener van het eigen serviceaccount van het cluster en ze zijn verkregen en in de cloud gehost op deze URL als gevolg van de --enable-oidc-issuer optie die u hierboven hebt ingesteld.

U kunt eventueel ook limieten voor de eigen machtigingen van de SSE configureren als een bevoegde resource die wordt uitgevoerd in het besturingsvlak door de toegangscontroller te OwnerReferencesPermissionEnforcement configureren. Deze toegangscontroller beperkt hoeveel de SSE andere objecten in het cluster kan wijzigen.

Op uw Kubernetes-cluster moet Kubernetes versie 1.27 of hoger worden uitgevoerd.

  1. Configureer uw kube-apiserver met het verlener-URL-veld en het afdwingen van machtigingen. Het volgende voorbeeld is voor een k3s-cluster. Het cluster kan verschillende methoden hebben voor het wijzigen van ARGUMENTEN voor API-servers: --kube-apiserver-arg="--service-account-issuer=${SERVICE_ACCOUNT_ISSUER}" and --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement".

    • Haal de URL van de verlener van het serviceaccount op.

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

    • Open het configuratiebestand van de K3s-server.

      sudo nano /etc/systemd/system/k3s.service

    • Bewerk de serverconfiguratie zodat deze eruitziet zoals in het volgende voorbeeld, waarbij <u SERVICE_ACCOUNT_ISSUER> vervangt door de bovenstaande uitvoer, echo $SERVICE_ACCOUNT_ISSUERwaarbij u de afsluitende slash van deze URL moet opnemen:

      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. Start uw kube-apiserver opnieuw op.

    sudo systemctl daemon-reload
sudo systemctl restart k3s

Een Azure Key Vault maken

Maak een Azure Key Vault en voeg een geheim toe. Als u al een Azure Key Vault en een geheim hebt, kunt u deze sectie overslaan.

  1. Een Azure Key Vault maken:

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

  2. Geef uzelf de machtigingen 'Secrets Officer' voor de kluis, zodat u een geheim kunt maken:

    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. Maak een geheim en werk het bij zodat u twee versies hebt:

    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'

Een door de gebruiker toegewezen beheerde identiteit maken

Maak vervolgens een door de gebruiker toegewezen beheerde identiteit en geef deze machtigingen voor toegang tot Azure Key Vault. Als u al een beheerde identiteit hebt met key vault-lezer- en Key Vault-geheimengebruikersmachtigingen voor Azure Key Vault, kunt u deze sectie overslaan. Zie Een door de gebruiker toegewezen beheerde identiteiten maken en Azure RBAC-geheim, sleutel- en certificaatmachtigingen gebruiken met Key Vault voor meer informatie.

  1. Maak de door de gebruiker toegewezen beheerde identiteit:

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

  2. Geef de gebruikersmachtigingen voor key vault-lezer en Key Vault-geheimen. Mogelijk moet u even wachten op de replicatie van het maken van de identiteit voordat deze opdrachten zijn geslaagd:

    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}

Een federatieve identiteitsreferentie maken

Maak een Kubernetes-serviceaccount voor de workload die toegang nodig heeft tot geheimen. Maak vervolgens een federatieve identiteitsreferentie om een koppeling te maken tussen de beheerde identiteit, de OIDC-serviceaccountverlener en het Kubernetes-serviceaccount.

  1. Maak een Kubernetes-serviceaccount dat wordt gefedereerd naar de beheerde identiteit. Aantekeningen maken met details van de gekoppelde door de gebruiker toegewezen beheerde identiteit.

    kubectl create ns ${KUBERNETES_NAMESPACE}

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

  2. Maak een federatieve identiteitsreferentie:

    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}

De SSE installeren en gebruiken

De SSE is beschikbaar als een Azure Arc-extensie. Een Kubernetes-cluster met Azure Arc kan worden uitgebreid met Kubernetes-extensies met Azure Arc. Extensies maken Azure-mogelijkheden in uw verbonden cluster mogelijk en bieden een azure Resource Manager-gestuurde ervaring voor het installatie- en levenscyclusbeheer van extensies.

cert-manager en trust-manager installeren

cert-manager en trust-manager zijn vereist voor beveiligde communicatie van logboeken tussen clusterservices en moeten worden geïnstalleerd vóór de Arc-extensie.

  1. Installeer cert-manager.

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

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

De SSE installeren

  • Installeer de SSE in uw cluster met Arc met behulp van de volgende opdracht:

    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

    Desgewenst kunt u desgewenst het standaardrotatiepollinterval wijzigen door het volgende toe te voegen --configuration-settings rotationPollIntervalInSeconds=<time_in_seconds>:

    Parameternaam Beschrijving Default value
    rotationPollIntervalInSeconds Hiermee geeft u op hoe snel de SSE het geheim controleert of bijwerken dat wordt beheerd. 3600 (1 uur)

De SSE configureren

Configureer de geïnstalleerde extensie met informatie over uw Azure Key Vault en welke geheimen u wilt synchroniseren met uw cluster door exemplaren van aangepaste Kubernetes-resources te definiëren. U maakt twee typen aangepaste resources:

  • Een SecretProviderClass object om de verbinding met de sleutelkluis te definiëren.
  • Een SecretSync object voor elk geheim dat moet worden gesynchroniseerd.

SecretProviderClass Een resource maken

De SecretProviderClass resource wordt gebruikt om de verbinding met Azure Key Vault te definiëren, de identiteit die moet worden gebruikt voor toegang tot de kluis, welke geheimen moeten worden gesynchroniseerd en het aantal versies van elk geheim dat lokaal moet worden bewaard.

U hebt een afzonderlijke SecretProviderClass naam nodig voor elke Azure Key Vault die u wilt synchroniseren, voor elke identiteit die wordt gebruikt voor toegang tot een Azure Key Vault en voor elke Kubernetes-doelnaamruimte.

Maak een of meer SecretProviderClass YAML-bestanden met de juiste waarden voor uw Key Vault en geheimen door dit voorbeeld te volgen.

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

SecretSync Een object maken

Elk gesynchroniseerd geheim vereist ook een SecretSync object om clusterspecifieke informatie te definiëren. Hier geeft u informatie op, zoals de naam van het geheim in uw cluster en namen voor elke versie van het geheim dat is opgeslagen in uw cluster.

Maak één SecretSync YAML-objectbestand voor elk geheim, volgens deze sjabloon. De Kubernetes-naamruimte moet overeenkomen met de naamruimte van de overeenkomende SecretProviderClassnaamruimte.

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

De configuratie-CA's toepassen

Pas de aangepaste configuratieresources (CR's) toe met behulp van de kubectl apply opdracht:

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

De SSE zoekt automatisch naar de geheimen en begint deze te synchroniseren met het cluster.

Configuratieopties weergeven

Als u aanvullende configuratieopties voor deze twee aangepaste resourcetypen wilt weergeven, gebruikt u de kubectl describe opdracht om de CRD's in het cluster te controleren:

# 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

Geheimen bekijken die worden gesynchroniseerd met het cluster

Zodra de configuratie is toegepast, beginnen geheimen automatisch te synchroniseren met het cluster volgens de frequentie die is opgegeven bij het installeren van de SSE.

Gesynchroniseerde geheimen weergeven

Bekijk de geheimen die zijn gesynchroniseerd met het cluster door de volgende opdracht uit te voeren:

# 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

Laatste synchronisatiestatus weergeven

Als u de status van de meest recente synchronisatie voor een bepaald geheim wilt weergeven, gebruikt u de kubectl describe opdracht voor het SecretSync object. De uitvoer bevat de tijdstempel voor het maken van geheimen, de versies van het geheim en gedetailleerde statusberichten voor elke synchronisatie-gebeurtenis. Deze uitvoer kan worden gebruikt om verbindings- of configuratiefouten vast te stellen en om te zien wanneer de geheime waarde verandert.

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

Geheimenwaarden weergeven

Gebruik de volgende opdracht om de gesynchroniseerde geheime waarden weer te geven die nu zijn opgeslagen in het Kubernetes-geheime archief:

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

Probleemoplossing

De SSE is een Kubernetes-implementatie die een pod met twee containers bevat: de controller, die het opslaan van geheimen in het cluster beheert, en de provider, waarmee de toegang tot en het ophalen van geheimen wordt beheerd, de Azure Key Vault. Elk gesynchroniseerd geheim heeft een SecretSync object dat de status van de synchronisatie van dat geheim van Azure Key Vault naar het clustergeheimarchief bevat.

Als u een probleem wilt oplossen, kijkt u eerst naar de status van het SecretSync object, zoals beschreven in De laatste synchronisatiestatus weergeven. De volgende tabel bevat veelvoorkomende statustypen, betekenissen en mogelijke stappen voor probleemoplossing om fouten op te lossen.

Statustype SecretSync DETAILS Stappen voor het oplossen/onderzoeken van verder onderzoek
CreateSucceeded Het geheim is gemaakt. n.v.t.
CreateFailedProviderError Het maken van geheimen is mislukt vanwege een probleem met de provider (verbinding met Azure Key Vault). Deze fout kan worden veroorzaakt door internetverbinding, onvoldoende machtigingen voor het synchroniseren van identiteiten, onjuiste configuratie van de SecretProviderClassof andere problemen. Onderzoek verder door de logboeken van de provider te bekijken met behulp van de volgende opdrachten:
kubectl get pods -n azure-secret-store
kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'
CreateFailedInvalidLabel Het maken van het geheim is mislukt omdat het geheim al bestaat zonder het juiste Kubernetes-label dat de SSE gebruikt om de geheimen te beheren. Verwijder het bestaande label en het bestaande geheim en laat de SSE het geheim opnieuw maken: kubectl delete secret <secret-name>
Als u wilt afdwingen dat de SSE het geheim sneller maakt dan het geconfigureerde poll-interval voor rotatie, verwijdert u het SecretSync object (kubectl delete secretsync <secret-name>) en past u de geheime synchronisatieklasse () opnieuw toe.kubectl apply -f <path_to_secret_sync>
CreateFailedInvalidAnnotation Het maken van geheimen is mislukt omdat het geheim al bestaat zonder de juiste Kubernetes-aantekening die door de SSE wordt gebruikt om de geheimen te beheren. Verwijder de bestaande aantekening en het geheim en laat de SSE het geheim opnieuw maken: kubectl delete secret <secret-name>
Als u wilt afdwingen dat de SSE het geheim sneller maakt dan het geconfigureerde poll-interval voor rotatie, verwijdert u het SecretSync object (kubectl delete secretsync <secret-name>) en past u de geheime synchronisatieklasse () opnieuw toe.kubectl apply -f <path_to_secret_sync>
UpdateNoValueChangeSucceeded De SSE heeft Azure Key Vault gecontroleerd op updates aan het einde van het geconfigureerde poll-interval, maar er zijn geen wijzigingen aangebracht om te synchroniseren. n.v.t.
UpdateValueChangeOrForceUpdateSucceeded De SSE heeft Azure Key Vault gecontroleerd op updates en de waarde is bijgewerkt. n.v.t.
UpdateFailedInvalidLabel Bijwerken van geheimen is mislukt omdat het label op het geheim dat door de SSE wordt gebruikt voor het beheren van de geheimen, is gewijzigd. Verwijder het bestaande label en geheim en laat de SSE het geheim opnieuw maken: kubectl delete secret <secret-name>
Als u wilt afdwingen dat de SSE het geheim sneller maakt dan het geconfigureerde poll-interval voor rotatie, verwijdert u het SecretSync object (kubectl delete secretsync <secret-name>) en past u de geheime synchronisatieklasse () opnieuw toe.kubectl apply -f <path_to_secret_sync>
UpdateFailedInvalidAnnotation Bijwerken van geheim is mislukt omdat de aantekening voor het geheim dat door de SSE wordt gebruikt voor het beheren van de geheimen, is gewijzigd. Verwijder de bestaande aantekening en het geheim en laat de SSE het geheim opnieuw maken: kubectl delete secret <secret-name>
Als u wilt afdwingen dat de SSE het geheim sneller maakt dan het geconfigureerde poll-interval voor rotatie, verwijdert u het SecretSync object (kubectl delete secretsync <secret-name>) en past u de geheime synchronisatieklasse () opnieuw toe.kubectl apply -f <path_to_secret_sync>
UpdateFailedProviderError Het bijwerken van het geheim is mislukt vanwege een probleem met de provider (verbinding met Azure Key Vault). Deze fout kan worden veroorzaakt door internetverbinding, onvoldoende machtigingen voor het synchroniseren van identiteiten, configuratie van de SecretProviderClassof andere problemen. Onderzoek verder door de logboeken van de provider te bekijken met behulp van de volgende opdrachten:
kubectl get pods -n azure-secret-store
kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'
UserInputValidationFailed Het bijwerken van het geheim is mislukt omdat de geheime synchronisatieklasse onjuist is geconfigureerd (zoals een ongeldig geheimtype). Controleer de definitie van de geheime synchronisatieklasse en corrigeer eventuele fouten. Verwijder vervolgens het SecretSync object (kubectl delete secretsync <secret-name>), verwijder de geheime synchronisatieklasse (kubectl delete -f <path_to_secret_sync>) en pas de geheime synchronisatieklasse (kubectl apply -f <path_to_secret_sync>) opnieuw toe.
ControllerSpcError Het bijwerken van het geheim is mislukt omdat de SSE de providerklasse niet kan ophalen of omdat de providerklasse onjuist is geconfigureerd. Controleer de providerklasse en corrigeer eventuele fouten. Verwijder vervolgens het SecretSync object (kubectl delete secretsync <secret-name>), verwijder de providerklasse (kubectl delete -f <path_to_provider>) en pas de providerklasse (kubectl apply -f <path_to_provider>opnieuw toe).
ControllerInternalError Het bijwerken van het geheim is mislukt vanwege een interne fout in de SSE. Controleer de SSE-logboeken of de gebeurtenissen voor meer informatie:
kubectl get pods -n azure-secret-store
kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='manager'
SecretPatchFailedUnknownError Bijwerken van geheimen is mislukt tijdens het patchen van de Kubernetes-geheime waarde. Deze fout kan optreden als het geheim is gewijzigd door iemand anders dan de SSE of als er problemen zijn opgetreden tijdens een update van de SSE. Verwijder het geheim en SecretSync object en laat de SSE het geheim opnieuw maken door de geheime synchronisatie CR opnieuw toe te past:
kubectl delete secret <secret-name>
kubectl delete secretsync <secret-name>
kubectl apply -f <path_to_secret_sync>

De SSE verwijderen

Als u de SSE wilt verwijderen en het synchroniseren van geheimen wilt stoppen, verwijdert u deze met de az k8s-extension delete opdracht:

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

Als u de extensie verwijdert, worden geheimen, SecretSync objecten of CRD's niet uit het cluster verwijderd. Deze objecten moeten rechtstreeks worden verwijderd met kubectl.

Als u secretsync CRD verwijdert, worden alle SecretSync objecten verwijderd en worden standaard alle geheimen in eigendom verwijderd, maar geheimen kunnen zich blijven voordoen als:

In de bovenstaande gevallen moeten geheimen rechtstreeks worden verwijderd met behulp van kubectl.

Volgende stappen