Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Utiliser des AWS Secrets Manager secrets dans Amazon Elastic Kubernetes Service Pour afficher les secrets AWS Secrets Manager (ASCP) sous forme de fichiers montés dans des pods Amazon EKS, vous pouvez utiliser le fournisseur de AWS secrets et de configuration pour le pilote CSI Kubernetes Secrets Store. L'ASCP fonctionne avec Amazon Elastic Kubernetes Service 1.17\$1 exécutant un groupe de nœuds Amazon EC2. AWS Fargate les groupes de nœuds ne sont pas pris en charge. Avec l'ASCP, vous pouvez stocker et gérer vos secrets dans Secrets Manager, puis les récupérer via vos applications exécutées sur Amazon EKS. Si votre secret contient plusieurs paires clé-valeur au format JSON, vous pouvez choisir celles à monter dans Amazon EKS. L’ASCP utilise la syntaxe JMESPath pour interroger les paires clé-valeur dans votre secret. L'ASCP fonctionne également avec les paramètres du Parameter Store. L’ASCP propose deux méthodes d’authentification avec Amazon EKS. La première approche utilise les rôles IAM pour les comptes de service (IRSA). La deuxième approche utilise les identités du pod. Chaque approche a ses avantages et cas d’utilisation. ## ASCP avec rôles IAM pour les comptes de service (IRSA) L'ASCP avec rôles IAM pour les comptes de service (IRSA) vous permet de monter des secrets AWS Secrets Manager sous forme de fichiers dans vos pods Amazon EKS. Cette approche convient lorsque : + Vous devez monter les secrets sous forme de fichiers dans vos pods. + Vous utilisez Amazon EKS version 1.17 ou ultérieure avec des groupes de nœuds Amazon EC2. + Vous souhaitez récupérer des paires clé-valeur spécifiques à partir de secrets au format JSON. Pour de plus amples informations, veuillez consulter [Utiliser AWS les secrets et le fournisseur de configuration CSI avec des rôles IAM pour les comptes de service (IRSA)](integrating_ascp_irsa.md). ## ASCP avec l’identité du pod La méthode ASCP avec Pod Identity améliore la sécurité et simplifie la configuration pour accéder aux secrets dans Amazon EKS. Cette approche est bénéfique lorsque : + Vous avez besoin d’une gestion des autorisations plus précise au niveau du pod. + Vous utilisez Amazon EKS version 1.24 ou ultérieure. + Vous souhaitez améliorer les performances et la capacité de mise à l’échelle. Pour de plus amples informations, veuillez consulter [Utiliser AWS les secrets et le fournisseur de configuration CSI avec Pod Identity pour Amazon EKS](ascp-pod-identity-integration.md). ## Choix de la bonne approche Tenez compte des facteurs suivants lorsque vous choisissez entre ASCP avec IRSA et ASCP avec l’identité du pod : + Amazon EKSversion : Pod Identity nécessite Amazon EKS 1.24\$1, tandis que le pilote CSI fonctionne avec Amazon EKS 1.17\$1. + Exigences de sécurité : l’identité du pod offre un contrôle plus granulaire au niveau du pod. + Performances : l’identité du pod fonctionne généralement mieux dans les environnements à grande échelle. + Complexité : l’identité du pod simplifie la configuration en éliminant le besoin de comptes de service distincts. Choisissez la méthode qui correspond le mieux à vos exigences spécifiques et à l’environnement Amazon EKS. # Installer l’ASCP pour Amazon EKS Cette section explique comment installer le fournisseur de AWS secrets et de configuration pour Amazon EKS. Avec ASCP, vous pouvez monter des secrets à partir de Secrets Manager et des paramètres AWS Systems Manager sous forme de fichiers dans Amazon EKS Pods. ## Conditions préalables + Un cluster Amazon EKS + Version 1.24 ou ultérieure pour l’identité du pod + Version 1.17 ou ultérieure pour IRSA + Le AWS CLI installé et configuré + kubectl installé et configuré pour votre cluster Amazon EKS + Helm (version 3.0 ou ultérieure) ## Installation et configuration de l’ASCP L'ASCP est disponible GitHub dans le référentiel [secrets-store-csi-provider-aws](https://github.com/aws/secrets-store-csi-driver-provider-aws). Le référentiel contient également des exemples de fichiers YAML pour créer et monter un secret. Pendant l’installation, vous pouvez configurer l’ASCP pour utiliser un point de terminaison FIPS. Pour obtenir la liste des points de terminaison , consultez [AWS Secrets Manager points de terminaison](asm_access.md#endpoints). **Pour installer l'ASCP en tant que module complémentaire EKS** 1. Installation `eksctl` ([instructions d'installation](https://docs.aws.amazon.com/eks/latest/eksctl/installation.html)) 1. Exécutez la commande suivante pour installer le module complémentaire avec la [configuration par défaut](https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/charts/secrets-store-csi-driver-provider-aws/values.yaml) : ``` eksctl create addon --cluster --name aws-secrets-store-csi-driver-provider ``` Si vous souhaitez configurer le module complémentaire, exécutez plutôt la commande d'installation suivante : ``` aws eks create-addon --cluster-name --addon-name aws-secrets-store-csi-driver-provider --configuration-values 'file://path/to/config.yaml' ``` Le fichier de configuration peut être un fichier YAML ou JSON. Pour consulter le schéma de configuration du module complémentaire, procédez comme suit : 1. Exécutez la commande suivante et notez la dernière version du module complémentaire : ``` aws eks describe-addon-versions --addon-name aws-secrets-store-csi-driver-provider ``` 1. Exécutez la commande suivante pour voir le schéma de configuration du module complémentaire, en le `` remplaçant par la version de l'étape précédente : ``` aws eks describe-addon-configuration --addon-name aws-secrets-store-csi-driver-provider --addon-version ``` **Installer l’ASCP à l’aide de Helm** 1. Pour vous assurer que le référentiel pointe vers les derniers graphiques, utilisez `helm repo update.`. 1. Installez le chart. Voici un exemple de `helm install` commande : ``` helm install -n kube-system secrets-provider-aws aws-secrets-manager/secrets-store-csi-driver-provider-aws ``` 1. Pour utiliser un point de terminaison FIPS, ajoutez l’indicateur suivant : `--set useFipsEndpoint=true` 1. Pour configurer la limitation, ajoutez l’indicateur suivant : `--set-json 'k8sThrottlingParams={"qps": "number of queries per second", "burst": "number of queries per second"}'` 1. Si le pilote CSI Secrets Store est déjà installé sur votre cluster, ajoutez l'indicateur suivant :`--set secrets-store-csi-driver.install=false`. Cela ignorera l'installation du pilote CSI Secrets Store en tant que dépendance. **Installer en utilisant le code YAML dans le référentiel** + Utilisez les commandes suivantes. ``` helm repo add secrets-store-csi-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts helm install -n kube-system csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/deployment/aws-provider-installer.yaml ``` ## Vérifier les installations Pour vérifier les installations de votre cluster EKS, du pilote Secrets Store CSI et du plug-in ASCP, procédez comme suit : 1. Vérifiez le cluster EKS : ``` eksctl get cluster --name clusterName ``` Cette commande doit renvoyer des informations sur votre cluster. 1. Vérifiez l’installation du pilote Secrets Store CSI : ``` kubectl get pods -n kube-system -l app=secrets-store-csi-driver ``` Vous devriez voir des pods s’exécuter avec des noms comme `csi-secrets-store-secrets-store-csi-driver-xxx`. 1. Vérifier l’installation du plug-in ASCP : ------ #### [ YAML installation ] ``` $ kubectl get pods -n kube-system -l app=csi-secrets-store-provider-aws ``` Exemple de sortie : ``` NAME READY STATUS RESTARTS AGE csi-secrets-store-provider-aws-12345 1/1 Running 0 2m ``` ------ #### [ Helm installation ] ``` $ kubectl get pods -n kube-system -l app=secrets-store-csi-driver-provider-aws ``` Exemple de sortie : ``` NAME READY STATUS RESTARTS AGE secrets-provider-aws-secrets-store-csi-driver-provider-67890 1/1 Running 0 2m ``` ------ Vous devriez voir des pods dans l’état `Running`. Après exécution de ces commandes, si tout est correctement configuré, vous devriez voir tous les composants fonctionner sans aucune erreur. Si vous rencontrez des problèmes, vous devrez peut-être les résoudre en vérifiant les journaux des pods spécifiques qui rencontrent des problèmes. ## Résolution des problèmes 1. Pour vérifier les journaux du fournisseur ASCP, exécutez : ``` kubectl logs -n kube-system -l app=csi-secrets-store-provider-aws ``` 1. Vérifiez l'état de tous les pods de l'espace de `kube-system` noms : ``` kubectl -n kube-system get pods ``` ``` kubectl -n kube-system logs pod/PODID ``` Tous les pods liés au pilote CSI et à l’ASCP doivent être dans l’état « En cours d’exécution ». 1. Vérifiez la version du pilote CSI : ``` kubectl get csidriver secrets-store.csi.k8s.io -o yaml ``` Cette commande doit renvoyer des informations sur le pilote CSI installé. ## Ressources supplémentaires Pour plus d’informations sur l’utilisation d’ASCP avec Amazon EKS, consultez les ressources suivantes : + [Utilisation de l’identité du pod avec Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html) + [AWS Pilote CSI Secrets Store activé GitHub](https://github.com/aws/secrets-store-csi-driver-provider-aws) # Utiliser AWS les secrets et le fournisseur de configuration CSI avec Pod Identity pour Amazon EKS L'intégration du fournisseur de AWS secrets et de configuration à l'agent Pod Identity pour Amazon Elastic Kubernetes Service améliore la sécurité, simplifie la configuration et améliore les performances des applications exécutées sur Amazon EKS. Pod Identity simplifie l'authentification IAM pour Amazon EKS lors de la récupération de secrets depuis Secrets Manager ou de paramètres depuis AWS Systems Manager Parameter Store. L’identité du pod Amazon EKS rationalise le processus de configuration des autorisations IAM pour les applications Kubernetes en permettant de configurer les autorisations directement via les interfaces Amazon EKS, en réduisant le nombre d’étapes et en éliminant le besoin de basculer entre les services Amazon EKS et IAM. L’identité du pod permet d’utiliser un seul rôle IAM sur plusieurs clusters sans mettre à jour les politiques de confiance et prend en charge les [balises de session de rôle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags) pour un contrôle d’accès plus granulaire. Cette approche simplifie non seulement la gestion des politiques en permettant la réutilisation des politiques d'autorisation entre les rôles, mais elle améliore également la sécurité en autorisant l'accès aux AWS ressources en fonction des balises correspondantes. ## Comment ça marche 1. L’identité du pod attribue un rôle IAM au pod. 1. ASCP utilise ce rôle pour s'authentifier auprès de. Services AWS 1. S'il est autorisé, l'ASCP récupère les secrets demandés et les met à la disposition du Pod. Pour plus d’informations, consultez [Comprendre le l’identité du pod Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html) dans le *Guide de l’utilisateur Amazon EKS*. ## Conditions préalables **Important** L’identité du pod n’est prise en charge que pour Amazon EKS dans le cloud. Elle n’est pas prise en charge pour [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/), [Red Hat OpenShift Service on AWS](https://aws.amazon.com/rosa/) ni pour les clusters Kubernetes autogérés sur les instances Amazon EC2. + Cluster Amazon EKS (version 1.24 ou ultérieure). + Accès à un AWS CLI cluster Amazon EKS via `kubectl` + Accès à deux Comptes AWS (pour un accès entre comptes) ## Installer l’agent d’identité du pod Amazon EKS Pour utiliser l’identité du pod avec votre cluster, vous devez installer le module complémentaire Agent d’identité du pod Amazon EKS. **Installer l’agent d’identité du pod** + Installez le module complémentaire Pod Identity Agent sur votre cluster : ``` eksctl create addon \ --name eks-pod-identity-agent \ --cluster clusterName \ --region region ``` ## Configurer l’ASCP avec l’identité du pod 1. Créez une politique d'autorisation qui accorde `secretsmanager:GetSecretValue` une `secretsmanager:DescribeSecret` autorisation aux secrets auxquels le Pod a besoin pour accéder. Pour un exemple de politique, consultez [Exemple : autorisation de lire et de décrire des secrets individuels](auth-and-access_iam-policies.md#auth-and-access_examples-read-and-describe). 1. Créez un rôle IAM qui peut être assumé par le principal de service Amazon EKS pour l’identité du pod : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` ------ Associez la politique IAM au rôle : ``` aws iam attach-role-policy \ --role-name MY_ROLE \ --policy-arn POLICY_ARN ``` 1. Créez une association d’identité du pod. Par exemple, consultez [Créer une association d’identité du pod](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html#pod-id-association-create) dans le *Guide de l’utilisateur Amazon EKS*. 1. Créez le `SecretProviderClass` qui spécifie les secrets à monter dans le Pod : ``` kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/examples/ExampleSecretProviderClass-PodIdentity.yaml ``` La principale différence dans `SecretProviderClass` entre IRSA et l’identité du pod réside dans le paramètre facultatif `usePodIdentity`. Il s’agit d’un champ facultatif qui détermine l’approche d’authentification. Lorsqu’il n’est pas spécifié, les rôles IAM pour les comptes de service (IRSA) sont utilisés par défaut. + Pour utiliser l’identité du pod EKS, utilisez l’une des valeurs suivantes : `"true", "True", "TRUE", "t", "T"`. + Pour utiliser IRSA de manière explicite, définissez l’une des valeurs suivantes : `"false", "False", "FALSE", "f", or "F"`. 1. Déployez le pod qui contient les secrets sous `/mnt/secrets-store` : ``` kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/examples/ExampleDeployment-PodIdentity.yaml ``` 1. Si vous utilisez un cluster Amazon EKS privé, assurez-vous que le VPC dans lequel se trouve le cluster possède un AWS STS point de terminaison. Pour en savoir plus sur la création d’un point de terminaison, consultez [Points de terminaison de VPC d’interface](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_interface_vpc_endpoints.html) dans le *Guide de l’utilisateur Gestion des identités et des accès AWS *. ### Vérifier le montage du secret Pour vérifier que le secret est correctement monté, exécutez la commande suivante : ``` kubectl exec -it $(kubectl get pods | awk '/pod-identity-deployment/{print $1}' | head -1) -- cat /mnt/secrets-store/MySecret ``` **Pour configurer Amazon EKS Pod Identity afin d'accéder aux secrets dans Secrets Manager** 1. Créez une politique d'autorisation qui accorde `secretsmanager:GetSecretValue` une `secretsmanager:DescribeSecret` autorisation aux secrets auxquels le Pod a besoin pour accéder. Pour un exemple de politique, consultez [Exemple : autorisation de lire et de décrire des secrets individuels](auth-and-access_iam-policies.md#auth-and-access_examples-read-and-describe). 1. Créez un secret dans Secrets Manager, si vous n'en avez pas déjà un. ## Dépannage Vous pouvez afficher la plupart des erreurs en décrivant le déploiement du pod. **Pour afficher les messages d'erreur pour votre conteneur** 1. Obtenez une liste de noms de pod à l’aide de la commande suivante. Si vous n'utilisez pas l'espace de noms par défaut, utilisez `-n NAMESPACE`. ``` kubectl get pods ``` 1. Pour décrire le Pod, dans la commande suivante, *PODID* utilisez l'ID du Pod indiqué dans les Pods que vous avez trouvés à l'étape précédente. Si vous n'utilisez pas l'espace de noms par défaut, utilisez `-n NAMESPACE`. ``` kubectl describe pod/PODID ``` **Pour voir les erreurs pour l'ASCP** + Pour obtenir plus d'informations dans les journaux du fournisseur, utilisez la commande suivante pour *PODID* utiliser l'ID du module *csi-secrets-store-provider-aws*. ``` kubectl -n kube-system get pods kubectl -n kube-system logs pod/PODID ``` # Utiliser AWS les secrets et le fournisseur de configuration CSI avec des rôles IAM pour les comptes de service (IRSA) **Topics** + [Conditions préalables](#prerequisites) + [Configurer le contrôle d'accès](#integrating_ascp_irsa_access) + [Identifier les secrets à monter](#integrating_ascp_irsa_mount) + [Dépannage](#integrating_ascp_irsa_trouble) ## Conditions préalables + Cluster Amazon EKS (version 1.17 ou ultérieure). + Accès à un AWS CLI cluster Amazon EKS via `kubectl` ## Configurer le contrôle d'accès L’ASCP récupère l’identité du pod Amazon EKS et l’échange pour un rôle IAM. Vous définissez des autorisations dans une politique IAM pour ce rôle IAM. Lorsque l'ASCP assume le rôle IAM, il a accès aux secrets que vous avez autorisés. Les autres conteneurs ne peuvent pas accéder aux secrets sauf si vous les associez également au rôle IAM. **Pour autoriser votre Amazon EKS Pod à accéder aux secrets dans Secrets Manager** 1. Créez une politique d'autorisation qui accorde `secretsmanager:GetSecretValue` une `secretsmanager:DescribeSecret` autorisation aux secrets auxquels le Pod a besoin pour accéder. Pour un exemple de politique, consultez [Exemple : autorisation de lire et de décrire des secrets individuels](auth-and-access_iam-policies.md#auth-and-access_examples-read-and-describe). 1. Créez un fournisseur OpenID Connect (OIDC) IAM pour le cluster si vous n'en avez pas déjà un. Pour plus d’informations, consultez [Créer un fournisseur IAM OIDC pour votre cluster](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html) dans le *Guide de l’utilisateur Amazon EKS*. 1. Créez un [Rôle IAM pour le compte de service](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) et attachez la politique. Pour plus d’informations, veuillez consulter [Créer un rôle IAM pour un compte de service](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html) dans le *Guide de l’utilisateur Amazon EKS*. 1. Si vous utilisez un cluster Amazon EKS privé, assurez-vous que le VPC dans lequel se trouve le cluster possède un AWS STS point de terminaison. Pour en savoir plus sur la création d’un point de terminaison, consultez [Points de terminaison de VPC d’interface](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_interface_vpc_endpoints.html) dans le *Guide de l’utilisateur Gestion des identités et des accès AWS *. ## Identifier les secrets à monter Pour déterminer quels secrets l'ASCP monte dans Amazon EKS en tant que fichiers du système de fichiers, vous devez créer un fichier YAML [SecretProviderClass](ascp-examples.md#ascp-examples-secretproviderclass). La `SecretProviderClass` liste répertorie les secrets à monter et le nom du fichier sous lequel les monter. La `SecretProviderClass` doit se trouver dans le même espace de noms que le pod Amazon EKS auquel il fait référence. ### Montez les secrets sous forme de fichiers [Les instructions suivantes montrent comment monter des secrets sous forme de fichiers à l'aide d'exemples de fichiers YAML .yaml et [ExampleSecretProviderClass.yaml](https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/examples/ExampleSecretProviderClass-IRSA.yaml). ExampleDeployment](https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/examples/ExampleDeployment-IRSA.yaml) **Pour monter des secrets dans Amazon EKS** 1. Appliquez la `SecretProviderClass` au pod : ``` kubectl apply -f ExampleSecretProviderClass.yaml ``` 1. Déployez votre pod : ``` kubectl apply -f ExampleDeployment.yaml ``` 1. L’ASCP monte les fichiers. ## Dépannage Vous pouvez afficher la plupart des erreurs en décrivant le déploiement du pod. **Pour afficher les messages d'erreur pour votre conteneur** 1. Obtenez une liste de noms de pod à l’aide de la commande suivante. Si vous n'utilisez pas l'espace de noms par défaut, utilisez `-n nameSpace`. ``` kubectl get pods ``` 1. Pour décrire le Pod, dans la commande suivante, *podId* utilisez l'ID du Pod indiqué dans les Pods que vous avez trouvés à l'étape précédente. Si vous n'utilisez pas l'espace de noms par défaut, utilisez `-n nameSpace`. ``` kubectl describe pod/podId ``` **Pour voir les erreurs pour l'ASCP** + Pour obtenir plus d'informations dans les journaux du fournisseur, utilisez la commande suivante pour *podId* utiliser l'ID du module *csi-secrets-store-provider-aws*. ``` kubectl -n kube-system get pods kubectl -n kube-system logs Pod/podId ``` + **Vérifiez que le CRD `SecretProviderClass` est installé :** ``` kubectl get crd secretproviderclasses.secrets-store.csi.x-k8s.io ``` Cette commande doit renvoyer des informations sur la définition de ressource personnalisée `SecretProviderClass`. + **Vérifiez que l' SecretProviderClass objet a été créé.** ``` kubectl get secretproviderclass SecretProviderClassName -o yaml ``` # AWS Exemples de code de secret et de fournisseur de configuration ## Exemples d’authentification et de contrôle d’accès pour l’ASCP ### Exemple : politique IAM autorisant le service d’identité du pod Amazon EKS (pods.eks.amazonaws.com) à assumer le rôle et à baliser la session : ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` ------ ## SecretProviderClass Vous utilisez YAML pour décrire les secrets à monter dans Amazon EKS à l'aide de l'ASCP. Pour obtenir des exemples, consultez [SecretProviderClass utilisation](#ascp-scenarios-secretproviderclass). ### SecretProviderClass Structure YAML ``` apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: name spec: provider: aws parameters: region: failoverRegion: pathTranslation: usePodIdentity: preferredAddressType: objects: ``` Le champ Paramètres contient les détails de la demande de montage : **region** (Facultatif) Le nom Région AWS du secret. Si vous n'utilisez pas ce champ, ASCP va rechercher la région à partir de l'annotation sur le nœud. Comme cette recherche ajoute une surcharge aux demandes de montage, nous vous recommandons de fournir la région pour les clusters qui utilisent un grand nombre de pods. Si vous spécifiez également `failoverRegion`, l'ASCP essaie de récupérer le secret des deux régions. Si l'une des régions renvoie une erreur 4xx, notamment en raison d'un problème d'authentification, l'ASCP ne monte aucun secret. Si le secret est récupéré avec succès de `region`, l'ASCP monte cette valeur secrète. Si le secret n'est pas récupéré correctement de `region`, mais qu'il l'est avec succès de `failoverRegion`, l'ASCP monte cette valeur secrète. **failoverRegion** (Facultatif) Si vous incluez ce champ, l'ASCP va essayer de récupérer le secret à partir des régions définies dans `region` et dans ce champ. Si l'une des régions renvoie une erreur 4xx, notamment en raison d'un problème d'authentification, l'ASCP ne monte aucun secret. Si le secret est récupéré avec succès de `region`, l'ASCP monte cette valeur secrète. Si le secret n'est pas récupéré correctement de `region`, mais qu'il l'est avec succès de `failoverRegion`, l'ASCP monte cette valeur secrète. Pour accéder à un exemple sur la façon de procéder, consultez [Basculement secret multirégional](#multi-region-failover). **pathTranslation** (Facultatif) Un caractère de substitution unique à utiliser si le nom de fichier dans Amazon EKS contient un caractère séparateur de chemin, tel que la barre oblique (/) sur Linux. L'ASCP ne peut pas créer un fichier monté possédant un caractère de séparation de chemin. Par contre, l'ASCP va remplacer le caractère séparateur de chemin par un autre caractère. Si vous n'utilisez pas ce champ, la valeur par défaut est le trait de soulignement (\$1). Par exemple, `My/Path/Secret` se monte en tant que `My_Path_Secret`. Pour empêcher la substitution de caractères, entrez la chaîne `False`. **usePodIdentity** (Facultatif) Détermine l’approche d’authentification. Lorsqu’il n’est pas spécifié, sa valeur par défaut est Rôles IAM pour les comptes de service (IRSA) (IRSA). + Pour utiliser l’identité du pod EKS, utilisez l’une des valeurs suivantes : `"true"`", `"True"`, `"TRUE"`, `"t"` ou `"T"`. + Pour utiliser IRSA de manière explicite, définissez l’une des valeurs suivantes : `"false"`, `"False"`, `"FALSE"`, `"f"` ou `"F"`"=. **preferredAddressType** (Facultatif) Spécifie le type d’adresse IP préféré pour les communications entre les points de terminaison de l’agent d’identité du pod. Le champ n’est applicable que lors de l’utilisation de la fonctionnalité d’identité du pod EKS et sera ignoré lors de l’utilisation des rôles IAM pour les comptes de service. Les valeurs ne sont pas sensibles à la casse. Les valeurs valides sont : + `"ipv4"`, `"IPv4"` «, ou `"IPV4"` — Forcer l'utilisation du point de IPv4 terminaison Pod Identity Agent + `"ipv6"``"IPv6"`, ou `"IPV6"` — Forcer l'utilisation du point de IPv6 terminaison Pod Identity Agent + non spécifié — Utilisez la sélection automatique du point de terminaison, en essayant d'abord le point de IPv4 terminaison et en revenant au IPv6 point de terminaison en cas d' IPv4 échec **objects** Chaîne contenant une déclaration YAML des secrets à monter. Nous vous recommandons d'utiliser une chaîne YAML multi-ligne ou un caractère pipe (\$1). **objectName** Obligatoire. Spécifie le nom du secret ou du paramètre à récupérer. Pour Secrets Manager, il s’agit du paramètre [https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html#API_GetSecretValue_RequestParameters](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html#API_GetSecretValue_RequestParameters), et il peut s’agir du nom convivial ou de l’ARN complet du secret. Pour le magasin de paramètres SSM, il s'agit [https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html#API_GetParameter_RequestParameters](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html#API_GetParameter_RequestParameters)du paramètre et il peut s'agir du nom ou de l'ARN complet du paramètre. **objectType** Obligatoire si vous n'utilisez pas d'ARN Secrets Manager pour `objectName`. Peut avoir la valeur `secretsmanager` ou `ssmparameter`. **objectAlias** (Facultatif) Nom de fichier du secret dans le pod Amazon EKS. Si vous ne spécifiez pas ce champ,`objectName` apparaît en tant que nom de fichier. **Autorisation du fichier** (Facultatif) Chaîne octale à 4 chiffres qui indique l'autorisation du fichier à utiliser pour le montage du secret. Si vous ne spécifiez pas ce champ, il sera défini par défaut sur`"0644"`. **objectVersion** (Facultatif) ID de version du secret. Déconseillé, car vous devez mettre à jour l'identifiant de la version à chaque fois que vous mettez le secret à jour. La version la plus récente est utilisée par défaut. Si vous incluez un `failoverRegion`, ce champ représente le champ principal `objectVersion`. **objectVersionLabel** (Facultatif) Alias de la version. La version par défaut est la plus récente AWSCURRENT. Pour de plus amples informations, veuillez consulter [Versions secrètes](whats-in-a-secret.md#term_version). Si vous incluez un `failoverRegion`, ce champ représente le champ principal `objectVersionLabel`. **jmesPath** (Facultatif) Carte des clés dans le secret des fichiers à monter dans Amazon EKS. Pour utiliser ce champ, votre valeur secrète doit être au format JSON. Si vous utilisez ce champ, vous devez inclure les sous-champs `path` et `objectAlias`. **path** Une clé issue d'une paire clé-valeur dans le JSON de la valeur secrète. Si le champ contient un trait d'union, utilisez des guillemets simples pour l'ignorer, par exemple : `path: '"hyphenated-path"'` **objectAlias** Le nom du fichier à monter dans le pod Amazon EKS. Si le champ contient un trait d'union, utilisez des guillemets simples pour l'ignorer, par exemple : `objectAlias: '"hyphenated-alias"'` **Autorisation du fichier** (Facultatif) Chaîne octale à 4 chiffres qui indique l'autorisation du fichier à utiliser pour le montage du secret. Si vous ne spécifiez pas ce champ, l'autorisation de fichier de l'objet parent sera utilisée par défaut. **failoverObject** (Facultatif) Si vous spécifiez ce champ, l'ASCP essaie de récupérer à la fois le secret spécifié dans le champ principal `objectName` et le secret spécifié dans le sous-champ `failoverObject` `objectName`. Si l'un ou l'autre renvoie une erreur 4xx, notamment pour un problème d'authentification, l'ASCP ne monte aucun secret. Si le secret est récupéré avec succès à partir du `objectName` principal, l'ASCP monte cette valeur secrète. Si le secret n'est pas récupéré correctement depuis le `objectName` principal, mais qu'il est récupéré correctement depuis le basculement `objectName`, l'ASCP monte cette valeur secrète. Si vous incluez ce champ, vous devez inclure le champ `objectAlias`. Pour accéder à un exemple sur la façon de procéder, consultez [Basculement vers un autre secret](#failover-secret). Vous allez généralement utiliser ce champ lorsque le secret de basculement n'est pas une réplique. Pour obtenir un exemple de spécification des capacités, consultez [Basculement secret multirégional](#multi-region-failover). **objectName** Nom ou ARN complet du secret de basculement. Si vous utilisez un ARN, la région de l'ARN doit correspondre au champ `failoverRegion`. **objectVersion** (Facultatif) ID de version du secret. Doit correspondre au principal `objectVersion`. Déconseillé, car vous devez mettre à jour l'identifiant de la version à chaque fois que vous mettez le secret à jour. La version la plus récente est utilisée par défaut. **objectVersionLabel** (Facultatif) Alias de la version. La version par défaut est la version la plus récente AWSCURRENT. Pour de plus amples informations, veuillez consulter [Versions secrètes](whats-in-a-secret.md#term_version). ### Créez une SecretProviderClass configuration de base pour monter des secrets dans vos pods Amazon EKS. ------ #### [ Pod Identity ] SecretProviderClass pour utiliser un secret dans le même cluster Amazon EKS : ``` apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: aws-secrets-manager spec: provider: aws parameters: objects: | - objectName: "mySecret" objectType: "secretsmanager" usePodIdentity: "true" ``` ------ #### [ IRSA ] ``` apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: deployment-aws-secrets spec: provider: aws parameters: objects: | - objectName: "MySecret" objectType: "secretsmanager" ``` ------ ### SecretProviderClass utilisation Utilisez ces exemples pour créer des SecretProviderClass configurations pour différents scénarios. #### Exemple : Monter des secrets par nom ou ARN Cet exemple montre comment monter trois types de secrets différents : + Un secret spécifié par un ARN complet + Un secret spécifié par son nom + Une version spécifique d'un secret ``` apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: aws-secrets spec: provider: aws parameters: objects: | - objectName: "arn:aws:secretsmanager:us-east-2:777788889999:secret:MySecret2-d4e5f6" - objectName: "MySecret3" objectType: "secretsmanager" - objectName: "MySecret4" objectType: "secretsmanager" objectVersionLabel: "AWSCURRENT" ``` #### Exemple : monter des paires clé-valeur à partir d'un secret Cet exemple montre comment monter des paires clé-valeur spécifiques à partir d'un secret au format JSON : ``` apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: aws-secrets spec: provider: aws parameters: objects: | - objectName: "arn:aws:secretsmanager:us-east-2:777788889999:secret:MySecret-a1b2c3" jmesPath: - path: username objectAlias: dbusername - path: password objectAlias: dbpassword ``` #### Exemple : monter des secrets par autorisation de fichier Cet exemple montre comment monter un secret avec une autorisation de fichier spécifique ``` apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: aws-secrets spec: provider: aws parameters: objects: | - objectName: "mySecret" objectType: "secretsmanager" filePermission: "0600" jmesPath: - path: username objectAlias: dbusername filePermission: "0400" ``` #### Exemple : exemples de configuration de basculement Ces exemples montrent comment configurer le basculement pour les secrets. ##### Basculement secret multirégional Cet exemple montre comment configurer le basculement automatique pour un secret répliqué dans plusieurs régions : ``` apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: aws-secrets spec: provider: aws parameters: region: us-east-1 failoverRegion: us-east-2 objects: | - objectName: "MySecret" ``` ##### Basculement vers un autre secret Cet exemple montre comment configurer le basculement vers un autre secret (pas une réplique) : ``` apiVersion: secrets-store.csi.x-k8s.io/v1 kind: SecretProviderClass metadata: name: aws-secrets spec: provider: aws parameters: region: us-east-1 failoverRegion: us-east-2 objects: | - objectName: "arn:aws:secretsmanager:us-east-1:777788889999:secret:MySecret-a1b2c3" objectAlias: "MyMountedSecret" failoverObject: - objectName: "arn:aws:secretsmanager:us-east-2:777788889999:secret:MyFailoverSecret-d4e5f6" ``` ## Ressources supplémentaires Pour plus d’informations sur l’utilisation d’ASCP avec Amazon EKS, consultez les ressources suivantes : + [Utilisation de l’identité du pod avec Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html) + [Utilisation des AWS secrets et du fournisseur de configuration](https://docs.aws.amazon.com/secretsmanager/latest/userguide/integrating_ascp_csi.html) + [AWS Pilote CSI Secrets Store activé GitHub](https://github.com/aws/secrets-store-csi-driver-provider-aws)