Utilisation gMSA for Linux conteneurs sur Fargate - Amazon Elastic Container Service

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 for Linux conteneurs sur Fargate

Amazon ECS prend en charge l'authentification Active Directory pour les conteneurs Linux sur Fargate via un type spécial de compte de service appelé compte de service géré de groupe (gMSA).

Linux applications réseau basées sur le réseau, telles que .NET Les applications principales peuvent utiliser Active Directory pour faciliter l'authentification et la gestion 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. Mais, parce que Linux les conteneurs ne peuvent pas être joints à un domaine, vous devez configurer un Linux conteneur avec lequel courir gMSA.

Considérations

Tenez compte des points suivants avant d'utiliser gMSA for Linux conteneurs sur Fargate :

  • Vous devez exécuter la version 1.4 ou ultérieure de Platform.

  • Vous pourriez avoir besoin d'un Windows ordinateur joint au domaine pour remplir les conditions requises. Par exemple, vous pourriez avoir besoin d'un Windows ordinateur joint au domaine pour créer le gMSA dans Active Directory avec PowerShell. Le RSAT Les PowerShell outils Active Director ne sont disponibles que pour Windows. Pour plus d'informations, consultez la section Installation des outils d'administration Active Directory.

  • Vous devez utiliser le mode sans domaine gMSA.

    Amazon ECS utilise un fichier de spécification des informations d'identification Active Directory (CredSpec). Ce fichier contient gMSA métadonnées utilisées pour propager le gMSA contexte du compte pour le conteneur. Vous générez le CredSpec , puis stockez-le dans un compartiment Amazon S3.

  • Une tâche ne peut prendre en charge qu'un seul Active Directory.

Prérequis

Avant d'utiliser gMSA pour la fonctionnalité des conteneurs Linux avec AmazonECS, veillez à 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 avez déjà un gMSA compte dans Active Directory et utilisateur autorisé à accéder au gMSA compte de service. Pour de plus amples informations, veuillez consulter Créer un utilisateur Active Directory pour domainless gMSA.

  • Vous disposez d'un compartiment Amazon S3. Pour plus d'informations, consultez la section Création d'un compartiment dans le guide de l'utilisateur Amazon S3.

Configuration gMSA-capable Linux Conteneurs 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.

  • Créer un utilisateur Active Directory pour domainless gMSA

    Lorsque vous utilisez le mode sans domaine gMSA, le conteneur n'est pas joint au domaine. Les autres applications qui s'exécutent sur le conteneur ne peuvent pas utiliser les informations d'identification pour accéder au domaine. Les tâches qui utilisent un domaine différent peuvent être exécutées sur le même conteneur. Vous indiquez le nom d'un secret AWS Secrets Manager dans CredSpec dans le fichier. Le secret doit contenir un nom d'utilisateur, un mot de passe et le domaine auquel se connecter.

    Cette fonctionnalité est similaire à gMSA support for non-domain-joined container hostsfonctionnalité. Pour plus d'informations sur la fonctionnalité Windows, voir gMSA architecture et améliorations sur le site Web de Microsoft Learn.

    1. Configurez un utilisateur dans votre domaine Active Directory. L'utilisateur d'Active Directory doit être autorisé à accéder au gMSA compte de service que vous utilisez dans les tâches.

    2. Vous disposez de sous-réseaux VPC et capables de résoudre le nom de domaine Active Directory. Configurez les DHCP options VPC with avec le nom de domaine qui pointe vers le nom du service Active Directory. Pour plus d'informations sur la configuration des DHCP options pour unVPC, consultez la section Travailler avec des ensembles d'DHCPoptions dans le guide de l'utilisateur d'Amazon Virtual Private Cloud.

    3. Créez un secret dans AWS Secrets Manager.

    4. Créez le fichier de spécification des informations d'identification.

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.

  1. Créez un utilisateur dans votre domaine Active Directory. L'utilisateur d'Active Directory doit être autorisé à accéder au gMSA comptes de service que vous utilisez dans les tâches.

  2. Après avoir créé l'utilisateur Active Directory, créez un secret dans AWS Secrets Manager. Pour plus d'informations, veuillez consulter Créer un secret AWS Secrets Manager.

  3. Entrez le nom d'utilisateur, le mot de passe et le domaine de l'utilisateur dans des paires JSON clé-valeur appelées password et usernamedomainName, respectivement.

    {"username":"username","password":"passw0rd", "domainName":"example.com"}
  4. 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'MySecretexemple par le Amazon Resource Name (ARN) de votre secret dans la Resource liste.

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": [ "arn:aws:secretsmanager:aws-region:111122223333:secret:MySecret" ] } ] }
    Note

    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.

  5. 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:GetObject", "s3:ListObject" ], "Resource": [ "arn:aws:s3:::{bucket_name}", "arn:aws:s3:::{bucket_name}/{object}" ] } ] }

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 gMSA métadonnées utilisées pour propager le gMSA contexte du compte pour Linux contenant. Vous générez le CredSpec et référencez-le dans le credentialSpecs champ de votre définition de tâche. Le CredSpec le fichier ne contient aucun secret.

Ce qui suit est un exemple CredSpec dans le fichier.

{ "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 et en le téléchargeant sur un Amazon S3

Vous créez un CredSpec en utilisant le CredSpec PowerShell module sur un Windows ordinateur joint au domaine. Suivez les étapes décrites dans la section Créer une spécification d'identification sur le Microsoft Site Web Learn.

Après avoir créé le fichier de spécification des informations d'identification, chargez-le dans un compartiment Amazon S3. Copiez le CredSpec fichier sur l'ordinateur ou l'environnement dans lequel vous exécutez AWS CLI des commandes.

Exécutez la AWS CLI commande suivante pour télécharger le CredSpec vers Amazon S3. Remplacez amzn-s3-demo-bucket par le nom de votre compartiment Simple Storage Service (Amazon S3). Vous pouvez stocker le fichier sous forme d'objet dans n'importe quel compartiment et à n'importe quel emplacement, mais vous devez autoriser l'accès à ce compartiment et à cet emplacement dans la stratégie que vous associez au rôle d'exécution des tâches.

Pour PowerShell, utilisez la commande suivante :

$ Write-S3Object -BucketName "amzn-s3-demo-bucket" -Key "ecs-domainless-gmsa-credspec" -File "gmsa-cred-spec.json"

La AWS CLI commande suivante utilise des barres obliques inverses qui sont utilisées par sh les interpréteurs de commandes compatibles.

$ aws s3 cp gmsa-cred-spec.json \ s3://amzn-s3-demo-bucket/ecs-domainless-gmsa-credspec