Partager via


Utiliser l’extension Magasin des secrets pour récupérer des secrets pour l’accès hors connexion dans les clusters Kubernetes avec Azure Arc

L’extension Magasin des secrets Azure Key Vault pour Kubernetes (« extension Magasin des secrets ») synchronise automatiquement les secrets d’un coffre de clés Azure Key Vault vers un cluster Kubernetes avec Azure Arc pour un accès hors connexion. Cela signifie que vous pouvez utiliser Azure Key Vault pour stocker, gérer et faire pivoter vos secrets, même lors de l’exécution de votre cluster Kubernetes dans un état semi-déconnecté. Les secrets synchronisés sont stockés dans le magasin de secrets du cluster, ce qui les rend utilisables en tant que secrets Kubernetes de toutes les façons habituelles : montés en tant que volumes de données, ou exposés en tant que variables d’environnement à un conteneur dans un pod.

Les secrets synchronisés sont des ressources métier critiques. L’extension Magasin des secrets les sécurise donc via des espaces de noms et des nœuds isolés, des stratégies RBAC (contrôle d’accès en fonction du rôle) ainsi que des autorisations limitées pour le synchronisateur de secrets. Pour une protection supplémentaire, chiffrez le magasin des secrets Kubernetes sur votre cluster.

Conseil

L’extension Magasin des secrets est recommandée dans les scénarios où un accès hors connexion est nécessaire, ou quand vous avez besoin de synchroniser des secrets dans le magasin des secrets Kubernetes. Si vous n’avez pas besoin de ces fonctionnalités, vous pouvez utiliser l’extension Fournisseur de secrets Azure Key Vault pour la gestion des secrets dans vos clusters Kubernetes avec Arc. Il n’est pas recommandé d’exécuter à la fois l’extension en ligne Fournisseur de secrets Azure Key Vault et l’extension Magasin des secrets hors connexion côte à côte dans un cluster.

Cet article vous montre comment installer et configurer l’extension Magasin des secrets en tant qu’extension Kubernetes avec Azure Arc.

Important

L’extension Magasin des secrets est en préversion. Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.

Prérequis

  • Un cluster avec Arc. Il peut s’agir d’un cluster auquel vous vous êtes connecté (les exemples fournis tout au long de ce guide utilisent un cluster K3s) ou d’un cluster AKS activé par Azure Arc géré par Microsoft. Le cluster doit exécuter Kubernetes version 1.27 ou ultérieure et se trouver dans l’une des régions prises en charge (USA Est, USA Est 2, USA Ouest, USA Ouest, USA Ouest 2, USA Ouest 3, Europe Ouest, Europe Nord). La région est définie par la région du groupe de ressources utilisée pour créer le cluster Arc.
  • Veillez à respecter les prérequis généraux pour les extensions de cluster, notamment concernant l’utilisation de la dernière version de l’extension Azure CLI k8s-extension.
  • cert-manager est requis pour prendre en charge TLS pour la communication des journaux intracluster. Les exemples présentés plus loin dans ce guide vous guident lors de l’installation. Pour plus d’informations sur cert-manager, consultez cert-manager.io

Installez Azure CLI, puis connectez-vous, si ce n’est pas déjà fait :

az login

Avant de commencer, définissez les variables d’environnement à utiliser pour la configuration des ressources Azure et de cluster. Si vous disposez déjà d’une identité managée, d’Azure Key Vault ou d’une autre ressource répertoriée ici, mettez à jour les noms dans les variables d’environnement de façon à refléter ces ressources.

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"

Activer la fédération des identités de charge de travail dans votre cluster

SSE utilise une fonctionnalité appelée « fédération d’identité de charge de travail » pour accéder aux secrets Azure Key Vault et les synchroniser. Cette section décrit comment configurer cette fonctionnalité. Les sections suivantes expliquent en détail comment l’utiliser.

Conseil

Les étapes suivantes sont basées sur le guide pratique pour configurer Kubernetes avec Arc avec la fédération des identités de charge de travail. Pour toute assistance supplémentaire, reportez-vous à cette documentation.

Si votre cluster n’est pas encore connecté à Azure Arc, suivez ces étapes. Durant ces étapes, activez la fédération des identités de charge de travail dans le cadre de la commande connect :

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

Si votre cluster est déjà connecté à Azure Arc, activez l’identité de charge de travail à l’aide de la commande update :

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

Configurez maintenant votre cluster pour émettre des jetons de compte de service avec une nouvelle URL d’émetteur (service-account-issuer) qui permet à Microsoft Entra ID de trouver les clés publiques nécessaires pour valider ces jetons. Ces clés publiques sont destinées à l’émetteur de jetons de compte de service propre au cluster. Elles ont été obtenues et hébergées dans le cloud à cette URL, dans la mesure où vous avez défini l’option --enable-oidc-issuer ci-dessus.

Le cas échéant, vous pouvez également configurer des limites sur les propres autorisations de l’extension Magasin des secrets en tant que ressource privilégiée s’exécutant dans le plan de contrôle en configurant le contrôleur d’admission OwnerReferencesPermissionEnforcement. Ce contrôleur d’admission limite les changements que l’extension Magasin des secrets peut apporter aux autres objets du cluster.

  1. Configurez votre kube-apiserver avec le champ d’URL de l’émetteur et l’application des autorisations. L’exemple suivant concerne un cluster k3s. Il se peut que votre cluster ait des moyens différents pour modifier les arguments du serveur d’API : --kube-apiserver-arg="--service-account-issuer=${SERVICE_ACCOUNT_ISSUER}" and --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement".

    • Obtenir l’URL d’émetteur de compte de service.

      export SERVICE_ACCOUNT_ISSUER="$(az connectedk8s show --name ${CLUSTER_NAME} --resource-group ${RESOURCE_GROUP} --query "oidcIssuerProfile.issuerUrl" --output tsv)"
      echo $SERVICE_ACCOUNT_ISSUER
      
    • Ouvrez le fichier de configuration du serveur K3s.

      sudo nano /etc/systemd/system/k3s.service
      
    • Modifiez la configuration du serveur pour qu’elle ressemble à l’exemple suivant, en remplaçant <SERVICE_ACCOUNT_ISSUER> par la sortie ci-dessus de echo $SERVICE_ACCOUNT_ISSUER, sans oublier d’inclure la barre oblique de fin de cette URL :

      ExecStart=/usr/local/bin/k3s \
        server --write-kubeconfig-mode=644 \
           --kube-apiserver-arg="--service-account-issuer=<SERVICE_ACCOUNT_ISSUER>" \
           --kube-apiserver-arg="--enable-admission-plugins=OwnerReferencesPermissionEnforcement"
      
  2. Redémarrez votre kube-apiserver.

    sudo systemctl daemon-reload
    sudo systemctl restart k3s
    

Créer un secret et configurer une identité pour y accéder

Pour accéder à un secret Azure Key Vault donné, et le synchroniser, l’extension Magasin des secrets nécessite l’accès à une identité managée Azure disposant des autorisations Azure appropriées pour accéder à ce secret. L’identité managée doit être liée à un compte de service Kubernetes à l’aide de la fonctionnalité d’identité de charge de travail que vous avez activée ci-dessus. L’extension Magasin des secrets utilise l’identité managée Azure fédérée associée pour tirer les secrets d’Azure Key Vault vers votre magasin des secrets Kubernetes. Les sections suivantes décrivent comment procéder à la configuration.

Créer un Azure Key Vault

Créez un coffre Azure Key Vault et ajoutez un secret. Si vous avez déjà un coffre et un secret Azure Key Vault, vous pouvez ignorer cette section.

  1. Créez un coffre de clés Azure :

    az keyvault create --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --name "${KEYVAULT_NAME}" --enable-rbac-authorization
    
  2. Accordez-vous des autorisations « Agent des secrets » sur le coffre, afin de pouvoir créer un secret :

    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. Créez un secret et mettez-le à jour pour avoir deux versions :

    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'
    

Créer une identité managée attribuée par l’utilisateur

Ensuite, créez une identité managée affectée par l’utilisateur et accordez-lui les autorisations nécessaires pour accéder à Azure Key Vault. Si vous disposez déjà d’une identité managée avec les autorisations Lecteur Key Vault et Utilisateur des secrets Key Vault pour Azure Key Vault, vous pouvez ignorer cette section. Pour plus d’informations, consultez Créer des identités managées affectées par l’utilisateur et Utiliser des autorisations de secret, de clé et de certificat Azure RBAC avec Key Vault.

  1. Créez l’identité managée affectée par l’utilisateur :

    az identity create --name "${USER_ASSIGNED_IDENTITY_NAME}" --resource-group "${RESOURCE_GROUP}" --location "${LOCATION}" --subscription "${SUBSCRIPTION}"
    
  2. Accordez à l’identité les autorisations Lecteur Key Vault et Utilisateur des secrets Key Vault. Vous devrez peut-être patienter un moment que la réplication de la création d’identité ait eu lieu avant que ces commandes réussissent :

    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}
    

Créer des informations d’identification d’identité fédérée

Créez un compte de service Kubernetes pour la charge de travail qui a besoin d’accéder aux secrets. Ensuite, créez des informations d’identification d’identité fédérée pour établir un lien entre l’identité managée, l’émetteur du compte de service OIDC et le compte de service Kubernetes.

  1. Créez un compte de service Kubernetes qui sera fédéré à l’identité managée. Annotez-le avec les détails de l’identité managée affectée par l’utilisateur associée.

    kubectl create ns ${KUBERNETES_NAMESPACE}
    
    cat <<EOF | kubectl apply -f -
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: ${SERVICE_ACCOUNT_NAME}
        namespace: ${KUBERNETES_NAMESPACE}
    EOF
    
  2. Créez des informations d’identification d’identité fédérée :

    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}
    

Installer l’extension Magasin des secrets

L’extension Magasin des secrets est disponible en tant qu’extension Azure Arc. Un cluster Kubernetes avec Azure Arc peut être étendu avec des extensions Kubernetes compatibles avec Azure Arc. Les extensions activent les fonctionnalités Azure sur votre cluster connecté, et fournissent une expérience basée sur Azure Resource Manager pour l’installation d’extension et la gestion du cycle de vie.

cert-manager et trust-manager sont également requis pour la communication sécurisée des journaux entre les services de cluster et doivent être installés avant l’extension Arc.

  1. Installer 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 
    
  2. Installer trust-manager.

    helm upgrade trust-manager jetstack/trust-manager --install --namespace cert-manager --wait
    
  3. Installez l’extension Magasin des secrets sur votre cluster avec Arc à l’aide de la commande suivante :

    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 
    

    Si vous le souhaitez, vous pouvez éventuellement modifier l’intervalle d’interrogation de rotation par défaut en ajoutant --configuration-settings rotationPollIntervalInSeconds=<time_in_seconds> :

    Nom du paramètre Description Valeur par défaut
    rotationPollIntervalInSeconds Spécifie la vitesse à laquelle l’extension Magasin des secrets vérifie ou met à jour le secret qu’elle gère. 3600 (1 heure)

Configurer l’extension Magasin des secrets

Configurez l’extension installée avec les informations relatives à votre instance Azure Key Vault et les secrets à synchroniser avec votre cluster en définissant des instances de ressources personnalisées Kubernetes. Vous créez deux types de ressources personnalisées :

  • Un objet SecretProviderClass pour définir la connexion au coffre de clés.
  • Un objet SecretSync pour chaque secret à synchroniser.

Créer une ressource SecretProviderClass

La ressource SecretProviderClass est utilisée pour définir la connexion à Azure Key Vault, l’identité à utiliser pour accéder au coffre, les secrets à synchroniser, et le nombre de versions de chaque secret à conserver localement.

Vous avez besoin d’un SecretProviderClassdistinct pour chaque coffre Azure Key Vault que vous envisagez de synchroniser, pour chaque identité utilisée pour l’accès à un coffre Azure Key Vault, et pour chaque espace de noms Kubernetes cible.

Créez un ou plusieurs fichiers YAML SecretProviderClass avec les valeurs appropriées pour votre coffre de clés et vos secrets en suivant cet exemple.

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

Créer un objet SecretSync

Chaque secret synchronisé nécessite également un objet SecretSync pour définir des informations propres au cluster. Ici, vous spécifiez des informations telles que le nom du secret dans votre cluster et les noms de chaque version du secret stockées dans votre cluster.

Créez un fichier YAML d’objet SecretSync pour chaque secret, en suivant ce modèle. L’espace de noms Kubernetes doit correspondre à l’espace de noms de l’objet SecretProviderClass correspondant.

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

Appliquer les ressources personnalisées de configuration

Appliquez les ressources personnalisées de configuration à l’aide de la commande kubectl apply :

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

L’extension Magasin des secrets recherche automatiquement les secrets, et commence à les synchroniser avec le cluster.

Afficher les options de configuration

Pour afficher des options de configuration supplémentaires pour ces deux types de ressources personnalisés, utilisez la commande kubectl describe afin d’inspecter les CRD dans le cluster :

# 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

Observer la synchronisation des secrets avec le cluster

Une fois la configuration appliquée, les secrets commencent à se synchroniser automatiquement au cluster à la cadence spécifiée au moment de l’installation de l’extension Magasin des secrets.

Afficher les secrets synchronisés

Affichez les secrets synchronisés avec le cluster en exécutant la commande suivante :

# 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

Afficher le dernier état de synchronisation

Pour afficher l’état de la synchronisation la plus récente pour un secret donné, utilisez la commande kubectl describe pour l’objet SecretSync. La sortie inclut l’horodatage de création du secret, les versions du secret, et les messages d’état détaillés pour chaque événement de synchronisation. Cette sortie peut être utilisée pour diagnostiquer les erreurs de connexion ou de configuration, et pour observer quand la valeur du secret change.

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

Afficher les valeurs des secrets

Pour afficher les valeurs des secrets synchronisées, maintenant stockées dans le magasin des secrets Kubernetes, utilisez la commande suivante :

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

Dépannage

L’extension Magasin des secrets est un déploiement Kubernetes qui contient un pod avec deux conteneurs : le contrôleur, qui gère le stockage des secrets dans le cluster, et le fournisseur, qui gère l’accès à Azure Key Vault ainsi que le tirage des secrets à partir de celui-ci. Chaque secret synchronisé a un objet SecretSync qui contient l’état de la synchronisation de ce secret d’Azure Key Vault vers le magasin des secrets du cluster.

Pour résoudre un problème, commencez par examiner l’état de l’objet SecretSync, comme décrit dans Afficher l’état de la dernière synchronisation. Le tableau suivant répertorie les types d’état courants, leurs significations, et les étapes de dépannage potentielles pour résoudre les erreurs.

Type d’état SecretSync Détails Étapes à suivre pour corriger ou procéder à une investigation avancée
CreateSucceeded Le secret a été créé avec succès. n/a
CreateFailedProviderError La création du secret a échoué en raison d’un problème avec le fournisseur (connexion à Azure Key Vault). Cet échec peut être dû à la connectivité Internet, à des autorisations insuffisantes pour l’identité synchronisant les secrets, à une configuration incorrecte de SecretProviderClass, ou à d’autres problèmes. Procédez à une investigation plus poussée en examinant les journaux du fournisseur à l’aide des commandes suivantes :
kubectl get pods -n azure-secret-store
kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'
CreateFailedInvalidLabel La création du secret a échoué, car le secret existe déjà sans l’étiquette Kubernetes appropriée, que l’extension Magasin des secrets utilise pour gérer ses secrets. Supprimez l’étiquette et le secret existants, puis autorisez l’extension Magasin des secrets à recréer le secret : kubectl delete secret <secret-name>
Pour forcer l’extension Magasin des secrets à recréer le secret plus rapidement que l’intervalle d’interrogation de rotation configuré, supprimez l’objet SecretSync (kubectl delete secretsync <secret-name>), puis réappliquez la classe de synchronisation des secrets (kubectl apply -f <path_to_secret_sync>).
CreateFailedInvalidAnnotation La création du secret a échoué, car le secret existe déjà sans l’annotation Kubernetes appropriée, que l’extension Magasin des secrets utilise pour gérer ses secrets. Supprimez l’annotation et le secret existants, puis autorisez l’extension Magasin des secrets à recréer le secret : kubectl delete secret <secret-name>
Pour forcer l’extension Magasin des secrets à recréer le secret plus rapidement que l’intervalle d’interrogation de rotation configuré, supprimez l’objet SecretSync (kubectl delete secretsync <secret-name>), puis réappliquez la classe de synchronisation des secrets (kubectl apply -f <path_to_secret_sync>).
UpdateNoValueChangeSucceeded L’extension Magasin des secrets a recherché des mises à jour d’Azure Key Vault à la fin de l’intervalle d’interrogation configuré, mais il n’existe aucun changement à synchroniser. n/a
UpdateValueChangeOrForceUpdateSucceeded L’extension Magasin des secrets a recherché des mises à jour d’Azure Key Vault, et a réussi à mettre à jour la valeur. n/a
UpdateFailedInvalidLabel La mise à jour du secret a échoué, car l’étiquette du secret que l’extension Magasin des secrets utilise pour gérer ses secrets a été modifiée. Supprimez l’étiquette et le secret existants, puis autorisez l’extension Magasin des secrets à recréer le secret : kubectl delete secret <secret-name>
Pour forcer l’extension Magasin des secrets à recréer le secret plus rapidement que l’intervalle d’interrogation de rotation configuré, supprimez l’objet SecretSync (kubectl delete secretsync <secret-name>), puis réappliquez la classe de synchronisation des secrets (kubectl apply -f <path_to_secret_sync>).
UpdateFailedInvalidAnnotation La mise à jour du secret a échoué, car l’annotation du secret que l’extension Magasin des secrets utilise pour gérer ses secrets a été modifiée. Supprimez l’annotation et le secret existants, puis autorisez l’extension Magasin des secrets à recréer le secret : kubectl delete secret <secret-name>
Pour forcer l’extension Magasin des secrets à recréer le secret plus rapidement que l’intervalle d’interrogation de rotation configuré, supprimez l’objet SecretSync (kubectl delete secretsync <secret-name>), puis réappliquez la classe de synchronisation des secrets (kubectl apply -f <path_to_secret_sync>).
UpdateFailedProviderError La mise à jour du secret a échoué en raison d’un problème avec le fournisseur (connexion à Azure Key Vault). Cet échec peut être dû à la connectivité Internet, à des autorisations insuffisantes pour l’identité synchronisant les secrets, à la configuration de SecretProviderClass, ou à d’autres problèmes. Procédez à une investigation plus poussée en examinant les journaux du fournisseur à l’aide des commandes suivantes :
kubectl get pods -n azure-secret-store
kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='provider-azure-installer'
UserInputValidationFailed La mise à jour du secret a échoué, car la classe de synchronisation du secret a été configurée de manière incorrecte (par exemple, le type de secret est non valide). Passez en revue la définition de la classe de synchronisation de secret et corrigez les erreurs éventuelles. Ensuite, supprimez l’objet SecretSync (kubectl delete secretsync <secret-name>), supprimez la classe de synchronisation de secret (kubectl delete -f <path_to_secret_sync>) et réappliquez la classe de synchronisation de secret (kubectl apply -f <path_to_secret_sync>).
ControllerSpcError La mise à jour du secret a échoué, car l’extension Magasin des secrets n’a pas pu obtenir la classe de fournisseur, ou celle-ci est mal configurée. Passez en revue la classe de fournisseur et corrigez les erreurs éventuelles. Ensuite, supprimez l’objet SecretSync (kubectl delete secretsync <secret-name>), supprimez la classe de fournisseur (kubectl delete -f <path_to_provider>) et réappliquez la classe de fournisseur (kubectl apply -f <path_to_provider>).
ControllerInternalError La mise à jour du secret a échoué en raison d’une erreur interne dans l’extension Magasin des secrets. Pour plus d’informations, consultez les journaux ou les événements relatifs à l’extension Magasin des secrets :
kubectl get pods -n azure-secret-store
kubectl logs <secret-sync-controller-pod-name> -n azure-secret-store --container='manager'
SecretPatchFailedUnknownError La mise à jour du secret a échoué lors de la mise à jour corrective de la valeur du secret Kubernetes. Cette défaillance peut se produire si le secret a été modifié par une personne, et non par l’extension Magasin des secrets, ou si des problèmes se sont produits durant une mise à jour de l’extension Magasin des secrets. Essayez de supprimer le secret et l’objet SecretSync, puis laissez l’extension Magasin des secrets recréer le secret en réappliquant la ressource personnalisée de synchronisation des secrets :
kubectl delete secret <secret-name>
kubectl delete secretsync <secret-name>
kubectl apply -f <path_to_secret_sync>

Supprimer l’extension Magasin des secrets

Pour supprimer l’extension Magasin des secrets et arrêter la synchronisation des secrets, désinstallez-la avec la commande az k8s-extension delete :

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

La désinstallation de l’extension ne supprime pas les secrets, les objets SecretSync ou les CRD du cluster. Ces objets doivent être supprimés directement avec kubectl.

La suppression de la CRD SecretSync supprime tous les objets SecretSync et, par défaut, supprime tous les secrets détenus, mais des secrets peuvent persister si :

  • Vous avez changer le propriétaire de l’un des secrets.
  • Vous avez modifié les paramètres de garbage collection dans votre cluster, y compris la définition de différents finaliseurs.

Dans les cas ci-dessus, les secrets doivent être supprimés directement à l’aide de kubectl.

Étapes suivantes