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

Article
09/30/2024

L’extension Magasin des secrets Azure Key Vault pour Kubernetes (« Magasin des secrets ») synchronise automatiquement les secrets d’une instance Azure Key Vault à 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. Le Magasin des secrets les sécurise par le biais de nœuds et d’espaces de noms isolés, de stratégies RBAC (contrôle d’accès en fonction du rôle) et d’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 pour les scénarios où l’accès hors connexion est nécessaire, ou si 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 Fournisseur de secrets Azure Key Vault en ligne et l’extension Magasin des secrets hors connexion côte à côte dans un cluster.

Cet article explique comment installer et configurer le Magasin des secrets en tant qu’extension Kubernetes avec Azure Arc.

Important

Le Magasin des secrets est actuellement 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 connecté à Azure Arc, exécutant Kubernetes version 1.27 ou ultérieure, et 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.
Les exemples de ce guide utilisent un cluster K3s.
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

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.

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"

Configurer une identité pour accéder aux secrets

Pour accéder à un secret Azure Key Vault donné et le synchroniser, le 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 via la fédération. Le compte de service Kubernetes est celui que vous utilisez dans un pod Kubernetes ou une autre charge de travail pour accéder aux secrets à partir du magasin des secrets Kubernetes. L’extension Magasin des secrets utilise l’identité managée Azure fédérée associée pour extraire les secrets d’Azure Key Vault vers votre magasin des secrets Kubernetes. Les sections suivantes décrivent comment procéder à la configuration.

Héberger des informations publiques OIDC concernant l’émetteur du compte de service de votre cluster

L’utilisation de l’identité fédérée vous oblige actuellement à configurer le stockage cloud de façon à héberger des informations au format OIDC concernant les clés publiques de l’émetteur du compte de service de votre cluster. Dans cette section, vous allez configurer une URL d’émetteur OIDC (Open ID Connect) sécurisée et publique à l’aide de Stockage Blob Azure, puis charger un document de découverte minimal dans le compte de stockage. Pour plus d’informations, consultez Configuration OIDC pour les clusters auto-gérés.

Création d’un compte de stockage Azure.

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

Remarque

« az storage account create » peut échouer si votre instance Azure n’a pas activé le service « Microsoft.Storage ». Si vous rencontrez un échec, inscrivez le fournisseur de ressources Microsoft.Storage dans votre abonnement.

Générez un document de découverte. Chargez-le sur le compte de stockage, puis vérifiez qu’il est accessible publiquement.

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"

Obtenez la clé publique de l’émetteur du compte de service de votre cluster à partir de sa clé privée. Vous devrez probablement exécuter cette commande en tant que superutilisateur. L’exemple suivant concerne k3s. Votre cluster peut stocker la clé privée de l’émetteur du compte de service à un autre emplacement.
```
sudo openssl rsa -in /var/lib/rancher/k3s/server/tls/service.key -pubout -out sa.pub
```
Téléchargez l’outil en ligne de commande azwi le plus récent, que vous pouvez utiliser pour créer un document JWKS à partir de la clé publique, et décompressez-le :
```
tar -xzf <path to downloaded azwi tar.gz>
```

Générez le document JWKS. Chargez-le sur le compte de stockage, puis vérifiez qu’il est accessible publiquement.

./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"

Configurer l’émetteur de jeton de compte de service de votre cluster avec l’URL hébergée

Votre cluster doit également être configuré pour émettre des jetons de compte de service avec un champ d’URL de l’émetteur (service-account-issuer) qui pointe vers le compte de stockage que vous avez créé dans la section précédente. Pour plus d’informations sur la configuration de la fédération, consultez Configuration du cluster pour un émetteur OIDC.

Si vous le souhaitez, vous pouvez configurer des limites sur les propres autorisations du Magasin des secrets en tant que ressource privilégiée s’exécutant dans le plan de contrôle en configurant le OwnerReferencesPermissionEnforcementcontrôleur d’admission . Ce contrôleur d’admission limite dans quelle mesure le magasin des secrets peut modifier d’autres objets dans le cluster.

Votre cluster Kubernetes doit exécuter Kubernetes version 1.27 ou ultérieure.

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".
- Obtenez l’URL de l’émetteur du compte de service.
```
echo $SERVICE_ACCOUNT_ISSUER
```
- Ouvrez le fichier de configuration du serveur K3s.
```
sudo nano /etc/systemd/system/k3s.service
```
- Modifiez la configuration du serveur afin qu’elle ressemble à l’exemple suivant, en remplaçant <SERVICE_ACCOUNT_ISSUER> par la sortie de 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"
```

Redémarrez votre kube-apiserver.

sudo systemctl daemon-reload
sudo systemctl restart k3s

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.

Créez un coffre de clés Azure :

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

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}

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.

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}"

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.

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

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 et utiliser le Magasin des secrets

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

Le Magasin des secrets est installé en tant qu’extension Azure Arc.

Installer cert-manager et trust-manager

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

Installer cert-manager.

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

Installer 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

Installer l’extension Azure Arc Magasin des secrets

Vérifiez que votre cluster Kubernetes est connecté à Azure Arc avant d’installer l’extension.

Définissez deux variables d’environnement pour le groupe de ressources et le nom de votre cluster connecté. Si vous avez suivi le guide de démarrage rapide fourni en lien plus haut, ces variables sont respectivement « AzureArcTest » et « AzureArcTest1 ».
```
export ARC_RESOURCE_GROUP="AzureArcTest"
export ARC_CLUSTER_NAME="AzureArcTest1"
```

Installez l’extension Magasin des secrets sur votre cluster avec Arc à l’aide de la commande suivante :

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

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 rapidité avec laquelle le Magasin des secrets vérifie ou met à jour le secret qu’il gère.	`3600` (1 heure)

Configurer le 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

Le 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 avec le cluster à la cadence spécifiée lors de l’installation du 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

Le 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 au coffre Azure Key Vault et l’extraction 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 correcte utilisée par le Magasin des secrets pour gérer ses secrets.	Supprimez l’étiquette et le secret existants, et autorisez le Magasin des secrets à recréer le secret : `kubectl delete secret <secret-name>` Pour forcer le 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>`) et 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 correcte utilisée par le Magasin des secrets pour gérer ses secrets.	Supprimez l’annotation et le secret existants, et autorisez le Magasin des secrets à recréer le secret : `kubectl delete secret <secret-name>` Pour forcer le 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>`) et réappliquez la classe de synchronisation des secrets (`kubectl apply -f <path_to_secret_sync>`).
`UpdateNoValueChangeSucceeded`	Le Magasin des secrets a vérifié auprès d’Azure Key Vault l’existence de mises à jour à la fin de l’intervalle d’interrogation configuré, mais aucune modification n’a été apportée à la synchronisation.	n/a
`UpdateValueChangeOrForceUpdateSucceeded`	Le Magasin des secrets a vérifié auprès d’Azure Key Vault l’existence de mises à jour, et a correctement mis à jour la valeur.	n/a
`UpdateFailedInvalidLabel`	La mise à jour du secret a échoué, car l’étiquette du secret utilisée par le Magasin des secrets pour gérer ses secrets a été modifiée.	Supprimez l’étiquette et le secret existants, et autorisez le Magasin des secrets à recréer le secret : `kubectl delete secret <secret-name>` Pour forcer le 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>`) et 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 utilisée par le Magasin des secrets pour gérer ses secrets a été modifiée.	Supprimez l’annotation et le secret existants, et autorisez le Magasin des secrets à recréer le secret : `kubectl delete secret <secret-name>` Pour forcer le 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>`) et 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 le 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 le Magasin des secrets.	Pour plus d’informations, consultez les journaux du Magasin des secrets ou les événements : `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. Cet échec peut se produire si le secret a été modifié par une personne autre que le Magasin des secrets, ou s’il y a eu des problèmes lors d’une mise à jour du Magasin des secrets.	Essayez de supprimer le secret et l’objet `SecretSync`, puis laissez le 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 le Magasin des secrets

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

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

Apprenez-en davantage sur les extensions Azure Arc.
En savoir plus sur Azure Key Vault.

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

Prérequis

Configurer une identité pour accéder aux secrets

Héberger des informations publiques OIDC concernant l’émetteur du compte de service de votre cluster

Configurer l’émetteur de jeton de compte de service de votre cluster avec l’URL hébergée

Créer un Azure Key Vault

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

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

Installer et utiliser le Magasin des secrets

Installer cert-manager et trust-manager

Installer l’extension Azure Arc Magasin des secrets

Configurer le Magasin des secrets

Créer une ressource `SecretProviderClass`

Créer un objet `SecretSync`

Appliquer les ressources personnalisées de configuration

Afficher les options de configuration

Observer la synchronisation des secrets avec le cluster

Afficher les secrets synchronisés

Afficher le dernier état de synchronisation

Afficher les valeurs des secrets

Dépannage

Supprimer le Magasin des secrets

Étapes suivantes

Commentaires

Ressources supplémentaires

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

Prérequis

Configurer une identité pour accéder aux secrets

Héberger des informations publiques OIDC concernant l’émetteur du compte de service de votre cluster

Configurer l’émetteur de jeton de compte de service de votre cluster avec l’URL hébergée

Créer un Azure Key Vault

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

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

Installer et utiliser le Magasin des secrets

Installer cert-manager et trust-manager

Installer l’extension Azure Arc Magasin des secrets

Configurer le Magasin des secrets

Créer une ressource SecretProviderClass

Créer un objet SecretSync

Appliquer les ressources personnalisées de configuration

Afficher les options de configuration

Observer la synchronisation des secrets avec le cluster

Afficher les secrets synchronisés

Afficher le dernier état de synchronisation

Afficher les valeurs des secrets

Dépannage

Supprimer le Magasin des secrets

Étapes suivantes

Commentaires

Ressources supplémentaires

Créer une ressource `SecretProviderClass`

Créer un objet `SecretSync`