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.
Utilisation gMSA pour les EC2 Linux conteneurs sur Amazon ECS
Amazon ECS prend en charge l'authentification Active Directory pour les conteneurs Linux EC2 via un type spécial de compte de service appelé compte de service géré de groupe (gMSA).
Les applications réseau Linux, comme les applications .NET Core, peuvent faire appel à Active Directory pour faciliter la gestion de l'authentification et des autorisations entre les utilisateurs et les services. Vous pouvez utiliser cette fonctionnalité en concevant des applications qui s'intègrent à Active Directory et s'exécutent sur des serveurs joints à un domaine. Toutefois, comme les conteneurs Linux ne peuvent pas être joints à un domaine, vous devez configurer un conteneur Linux pour qu'il soit exécuté avec gMSA.
Un Linux conteneur qui s'exécute avec gMSA repose sur le credentials-fetcher
daemon qui s'exécute sur l'EC2instance Amazon hôte du conteneur. En d'autres termes, le démon récupère les informations d'identification gMSA auprès du contrôleur de domaine Active Directory, puis les transfère à l'instance de conteneur. Pour plus d'informations sur les comptes de service, veuillez consulter Créer des gMSAs pour des conteneurs Windows
Considérations
Tenez compte des points suivants avant d'utiliser des gMSA pour les conteneurs Linux :
-
Si vos conteneurs fonctionnent encoreEC2, vous pouvez les utiliser gMSA pour les Windows conteneurs et les Linux conteneurs. Pour plus d'informations sur l'utilisation gMSA du conteneur Linux sur Fargate, consultez. Utilisation gMSA pour les Linux conteneurs sur Fargate
-
Vous aurez peut-être besoin d'un ordinateur Windows joint au domaine pour remplir les conditions requises. Par exemple, vous pourriez avoir besoin d'un ordinateur Windows joint au domaine pour créer le gMSA dans Active Directory avec PowerShell. Les PowerShell outils RSAT Active Director ne sont disponibles que pourWindows. Pour plus d'informations, veuillez consulter Installation des outils d'administration Active Directory (langue française non garantie).
-
Vous avez choisi entre les gMSA sans domaine et joindre chaque instance à un seul domaine. En utilisant les gMSA sans domaine, l'instance de conteneur n'est pas jointe au domaine, les autres applications de l'instance ne peuvent pas utiliser les informations d'identification pour accéder au domaine et les tâches qui joignent différents domaines peuvent s'exécuter sur la même instance.
Choisissez ensuite le stockage de données pour CredSpec et, éventuellement, pour les informations d'identification utilisateur Active Directory pour les gMSA sans domaine.
Amazon ECS utilise un fichier de spécification des informations d'identification Active Directory (CredSpec). Ce fichier contient les métadonnées gMSA servant à propager le contexte du compte gMSA au conteneur. Vous générez le fichier CredSpec, puis vous le stockez dans l'une des options de stockage CredSpec du tableau suivant, spécifique au système d'exploitation des instances de conteneur. Pour utiliser la méthode sans domaine, une section facultative du fichier CredSpec peut spécifier les informations d'identification dans l'une des options de stockage domainless user credentials du tableau suivant, spécifiques au système d'exploitation des instances de conteneur.
Options de stockage de données gMSA par système d'exploitationEmplacement de stockage Linux Windows Amazon Simple Storage Service CredSpec CredSpec AWS Secrets Manager informations d'identification utilisateur sans domaine informations d'identification utilisateur sans domaine Boutique de paramètres Amazon EC2 Systems Manager CredSpec CredSpec, informations d'identification utilisateur sans domaine Fichier local N/A CredSpec
Prérequis
Avant d'utiliser la fonctionnalité gMSA pour les conteneurs Linux avec AmazonECS, assurez-vous d'effectuer les opérations suivantes :
-
Vous configurez un domaine Active Directory avec les ressources auxquelles vous souhaitez que vos conteneurs accèdent. Amazon ECS prend en charge les configurations suivantes :
-
Un AWS Directory Service Active Directory. AWS Directory Service est un Active Directory AWS géré hébergé sur AmazonEC2. Pour plus d'informations, consultez Getting Started with AWS Managed Microsoft AD dans le Guide d'AWS Directory Service administration.
-
Un répertoire Active Directory sur site. Vous devez vous assurer que l'instance de conteneur Amazon ECS Linux peut rejoindre le domaine. Pour de plus amples informations, veuillez consulter AWS Direct Connect.
-
-
Vous disposez d'un compte gMSA existant dans l'Active Directory. Pour de plus amples informations, veuillez consulter Utilisation gMSA pour les EC2 Linux conteneurs sur Amazon ECS.
-
Vous avez installé et exécutez le
credentials-fetcher
daemon sur une instance de conteneur Amazon ECS Linux. Vous avez également ajouté un jeu initial d'informations d'identification au démoncredentials-fetcher
pour vous authentifier auprès d'Active Directory.Note
Le démon
credentials-fetcher
est uniquement disponible pour Amazon Linux 2023 et Fedora 37 et versions ultérieures. Le démon n'est pas disponible pour Amazon Linux 2. Pour plus d'informations, consultez aws/credentials-fetcheron. GitHub -
Vous configurez les informations d'identification permettant au démon
credentials-fetcher
de s'authentifier auprès d'Active Directory. Les informations d'identification doivent être membres du groupe de sécurité Active Directory qui a accès au compte gMSA. Il existe plusieurs options dans Décidez si vous souhaitez joindre les instances au domaine ou utiliser le gMSA sans domaine.. -
Vous avez ajouté les IAM autorisations requises. Les autorisations requises dépendent des méthodes que vous choisissez pour les informations d'identification initiales et pour le stockage de la spécification des informations d'identification :
-
Si vous utilisez domainless gMSA pour les informations d'identification initiales, IAM des autorisations pour AWS Secrets Manager sont requises pour le rôle d'exécution de la tâche.
-
Si vous stockez la spécification des informations d'identification dans SSM Parameter Store, IAM les autorisations pour Amazon EC2 Systems Manager Parameter Store sont requises pour le rôle d'exécution de la tâche.
-
Si vous stockez la spécification des informations d'identification dans Amazon S3, IAM des autorisations pour Amazon Simple Storage Service sont requises pour le rôle d'exécution de la tâche.
-
Configuration de Linux conteneurs gMSA compatibles sur Amazon ECS
Préparation de l'infrastructure
Les étapes suivantes sont des considérations et une configuration qui ne sont effectuées qu'une seule fois. Après avoir terminé ces étapes, vous pouvez automatiser la création d'instances de conteneur afin de réutiliser cette configuration.
Décidez de la manière dont les informations d'identification initiales sont fournies et configurez les données EC2 utilisateur dans un modèle de EC2 lancement réutilisable pour installer le credentials-fetcher
daemon.
-
Décidez si vous souhaitez joindre les instances au domaine ou utiliser le gMSA sans domaine.
-
Joindre EC2 des instances au domaine Active Directory
-
Jointure des instances par les données utilisateur
Ajoutez les étapes permettant de joindre le domaine Active Directory à vos données EC2 utilisateur dans un modèle de EC2 lancement. Plusieurs groupes Amazon EC2 Auto Scaling peuvent utiliser le même modèle de lancement.
Vous pouvez suivre ces étapes pour Rejoindre un Active Directory ou un domaine FreeIPA
dans les Fedora Docs (langue française non garantie).
-
-
Création d'un utilisateur Active Directory pour gMSA sans domaine
Le démon
credentials-fetcher
possède une fonctionnalité appelée gMSA sans domaine. Cette fonctionnalité nécessite un domaine, mais il n'est pas nécessaire que l'EC2instance soit jointe au domaine. En utilisant les gMSA sans domaine, l'instance de conteneur n'est pas jointe au domaine, les autres applications de l'instance ne peuvent pas utiliser les informations d'identification pour accéder au domaine et les tâches qui joignent différents domaines peuvent s'exécuter sur la même instance. Vous devez plutôt fournir le nom d'un secret d' AWS Secrets Manager dans le fichier CredSpec. Le secret doit contenir un nom d'utilisateur, un mot de passe et le domaine auquel se connecter.Cette fonctionnalité est prise en charge et peut être utilisée avec les conteneurs Linux et Windows.
Cette fonctionnalité est similaire à la fonctionnalité gMSA support for non-domain-joined container hosts. Pour plus d'informations sur la fonctionnalité Windows, veuillez consulter Architecture et améliorations des gMSA
sur le site Web de Microsoft Learn. -
Créez un utilisateur dans votre domaine Active Directory. L'utilisateur d'Active Directory doit être autorisé à accéder aux comptes de service gMSA que vous utilisez dans les tâches.
-
Créez un secret dans AWS Secrets Manager, après avoir créé l'utilisateur dans Active Directory. Pour plus d'informations, voir Création d'un AWS Secrets Manager secret.
-
Entrez le nom d'utilisateur, le mot de passe et le domaine de l'utilisateur dans des paires JSON clé-valeur appelées
password
etusername
domainName
, respectivement.{"username":"
username
","password":"passw0rd
", "domainName":"example.com"} -
Ajoutez la configuration au fichier CredSpec pour le compte de service. L'annexe
HostAccountConfig
contient le nom de ressource Amazon (ARN) du secret dans Secrets Manager.Sous Windows, le
PluginGUID
doit correspondre à celui indiqué GUID dans l'exemple d'extrait de code suivant. Sous Linux, lePluginGUID
est ignoré.MySecret
Remplacez-le par l'exemple par le Amazon Resource Name (ARN) de votre secret."ActiveDirectoryConfig": { "HostAccountConfig": { "PortableCcgVersion": "1", "PluginGUID": "{859E1386-BDB4-49E8-85C7-3070B13920E1}", "PluginInput": { "CredentialArn": "
arn:aws:secretsmanager:
" } }aws-region
:111122223333:secret:MySecret -
La fonctionnalité gMSA sans domaine nécessite des autorisations supplémentaires dans le rôle d'exécution des tâches. Suivez l'étape (Facultatif) secret gMSA sans domaine.
-
-
-
Configurez des instances et installez le démon
credentials-fetcher
.Vous pouvez installer le
credentials-fetcher
daemon avec un script de données utilisateur dans votre modèle de EC2 lancement. Les exemples suivants illustrent deux types de données utilisateur,cloud-config
YAML ou le script bash. Ces exemples concernent Amazon Linux 2023 (AL2023).MyCluster
Remplacez-le par le nom du ECS cluster Amazon auquel vous souhaitez que ces instances rejoignent.-
cloud-config
YAMLContent-Type: text/cloud-config package_reboot_if_required: true packages: # prerequisites - dotnet - realmd - oddjob - oddjob-mkhomedir - sssd - adcli - krb5-workstation - samba-common-tools # https://github.com/aws/credentials-fetcher gMSA credentials management for containers - credentials-fetcher write_files: # configure the ECS Agent to join your cluster. # replace MyCluster with the name of your cluster. - path: /etc/ecs/ecs.config owner: root:root permissions: '0644' content: | ECS_CLUSTER=
MyCluster
ECS_GMSA_SUPPORTED=true runcmd: # start the credentials-fetcher daemon and if it succeeded, make it start after every reboot - "systemctl start credentials-fetcher" - "systemctl is-active credentials-fetch && systemctl enable credentials-fetcher" -
Script bash
Si vous êtes plus à l'aise avec les scripts bash et que vous avez plusieurs variables à écrire dans
/etc/ecs/ecs.config
, utilisez le formatheredoc
suivant. Ce format écrit tout entre les lignes commençant par cat etEOF
dans le fichier de configuration.#!/usr/bin/env bash set -euxo pipefail # prerequisites timeout 30 dnf install -y dotnet realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation samba-common-tools # install https://github.com/aws/credentials-fetcher gMSA credentials management for containers timeout 30 dnf install -y credentials-fetcher # start credentials-fetcher systemctl start credentials-fetcher systemctl is-active credentials-fetch && systemctl enable credentials-fetcher cat <<'EOF' >> /etc/ecs/ecs.config ECS_CLUSTER=
MyCluster
ECS_GMSA_SUPPORTED=true EOF
Il existe des variables de configuration facultatives pour le démon
credentials-fetcher
que vous pouvez définir dans/etc/ecs/ecs.config
. Nous vous recommandons de définir les variables dans les données utilisateur du YAML bloc ou deheredoc
manière similaire aux exemples précédents. Cela permet d'éviter les problèmes de configuration partielle qui peuvent survenir lors de la modification d'un fichier à plusieurs reprises. Pour plus d'informations sur la configuration de l'ECSagent, consultez Amazon ECS Container Agenton GitHub. -
Vous pouvez éventuellement utiliser la variable
CREDENTIALS_FETCHER_HOST
si vous modifiez la configuration du démoncredentials-fetcher
pour déplacer le socket vers un autre emplacement.
-
Configuration des autorisations et des secrets
Effectuez les étapes suivantes une fois pour chaque application et chaque définition de tâche. Nous vous recommandons d'utiliser le principe de moindre privilège et d'affiner les autorisations utilisées dans la stratégie. Ainsi, chaque tâche ne peut lire que les secrets dont elle a besoin.
-
(Facultatif) secret gMSA sans domaine
Si vous utilisez la méthode sans domaine dans laquelle l'instance n'est pas jointe au domaine, procédez comme suit.
Vous devez ajouter les autorisations suivantes en tant que politique intégrée au IAM rôle d'exécution des tâches. Cela permet au démon
credentials-fetcher
d'accéder au secret Secrets Manager. Remplacez l'MySecret
exemple par le Amazon Resource Name (ARN) de votre secret dans laResource
liste.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": [ "
arn:aws:ssm:
" ] } ] }aws-region
:111122223333:secret:MySecretNote
Si vous utilisez votre propre KMS clé pour chiffrer votre secret, vous devez ajouter les autorisations nécessaires à ce rôle et ajouter ce rôle à la politique des AWS KMS clés.
-
Décidez si vous utilisez SSM Parameter Store ou S3 pour stocker le CredSpec
Amazon ECS prend en charge les méthodes suivantes pour référencer le chemin du fichier dans le
credentialSpecs
champ de définition de la tâche.Si vous associez les instances à un seul domaine, utilisez le préfixe
credentialspec:
au début de la ARN chaîne. Si vous utilisez le gMSA sans domaine, utilisezcredentialspecdomainless:
.Pour en savoir plus sur CredSpec, consultez Fichier de spécification des informations d'identification.
-
Compartiment Amazon S3
Ajoutez la spécification d'informations d'identification à un compartiment Amazon S3. Référencez ensuite le nom de ressource Amazon (ARN) du compartiment Amazon S3 dans le
credentialSpecs
champ de définition de la tâche.{ "family": "", "executionRoleArn": "", "containerDefinitions": [ { "name": "", ... "credentialSpecs": [ "credentialspecdomainless:arn:aws:s3:::
${BucketName}/${ObjectName}
" ], ... } ], ... }Pour permettre à vos tâches d'accéder au compartiment S3, ajoutez les autorisations suivantes en tant que politique intégrée au IAM rôle d'exécution des ECS tâches Amazon.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor", "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::
amzn-s3-demo-bucket
", "arn:aws:s3:::amzn-s3-demo-bucket/{object}
" ] } ] } -
Paramètre SSM Parameter Store
Ajoutez la spécification d'identification à un SSM paramètre Parameter Store. Référencez ensuite le nom de ressource Amazon (ARN) du SSM paramètre Parameter Store dans le
credentialSpecs
champ de définition de la tâche.{ "family": "", "executionRoleArn": "", "containerDefinitions": [ { "name": "", ... "credentialSpecs": [ "credentialspecdomainless:arn:aws:ssm:
aws-region
:111122223333
:parameter/parameter_name
" ], ... } ], ... }Pour donner à vos tâches l'accès au SSM paramètre Parameter Store, ajoutez les autorisations suivantes en tant que politique intégrée au IAM rôle d'exécution des ECS tâches Amazon.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssm:GetParameters" ], "Resource": [ "arn:aws:ssm:
aws-region
:111122223333
:parameter/parameter_name
" ] } ] }
-
Fichier de spécification des informations d'identification
Amazon ECS utilise un fichier de spécification des informations d'identification Active Directory (CredSpec). Ce fichier contient les métadonnées gMSA servant à propager le contexte du compte gMSA au conteneur Linux. Vous générez le CredSpec et le référencez dans le champ credentialSpecs
de votre définition de tâche. Le fichier CredSpec ne contient aucun secret.
Voici un exemple de fichier CredSpec.
{
"CmsPlugins": [
"ActiveDirectory"
],
"DomainJoinConfig": {
"Sid": "S-1-5-21-2554468230-2647958158-2204241789",
"MachineAccountName": "WebApp01",
"Guid": "8665abd4-e947-4dd0-9a51-f8254943c90b",
"DnsTreeName": "example.com",
"DnsName": "example.com",
"NetBiosName": "example"
},
"ActiveDirectoryConfig": {
"GroupManagedServiceAccounts": [
{
"Name": "WebApp01",
"Scope": "example.com"
}
],
"HostAccountConfig": {
"PortableCcgVersion": "1",
"PluginGUID": "{859E1386-BDB4-49E8-85C7-3070B13920E1}",
"PluginInput": {
"CredentialArn": "arn:aws:secretsmanager:aws-region
:111122223333:secret:MySecret
"
}
}
}
}
Création d’un CredSpec
Vous créez un CredSpec en utilisant le module PowerShell CredSpec sur un ordinateur Windows joint au domaine. Suivez les étapes décrites dans Créer une spécification d'informations d'identification