Utilisation gMSA pour les Linux conteneurs sur Fargate - Amazon Elastic Container Service
ConsidérationsPrérequisConfigurationCredSpec file

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

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.

Considérations

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

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

  • 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 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 les métadonnées gMSA servant à propager le contexte du compte gMSA au conteneur. Vous générez le CredSpec fichier, puis vous le stockez dans un compartiment Amazon S3.

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

Prérequis

Avant d'utiliser la fonctionnalité gMSA pour les conteneurs Linux avec Amazon ECS, assurez-vous de remplir les conditions 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 Amazon EC2. 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 Linux Amazon ECS peut se joindre au domaine. Pour plus d’informations, consultez AWS Direct Connect.

  • Vous disposez d'un gMSA compte existant dans Active Directory et d'un utilisateur autorisé à accéder au compte gMSA de service. Pour plus d’informations, consultez Création d'un utilisateur Active Directory pour gMSA sans domaine.

  • 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 de conteneurs Linux compatibles avec gMSA 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éation d'un utilisateur Active Directory pour gMSA sans domaine

    Lorsque vous utilisez l'option sans domainegMSA, 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 le CredSpec fichier. Le secret doit contenir un nom d'utilisateur, un mot de passe et le domaine auquel se connecter.

    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.

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

    2. Vous disposez d'un VPC et de sous-réseaux capables de résoudre le nom de domaine Active Directory. Configurez le VPC avec les options DHCP avec le nom de domaine qui pointe vers le nom du service Active Directory. Pour plus d'informations sur la configuration des options DHCP pour un VPC, consultez la section Travailler avec des ensembles d'options DHCP 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 aux comptes de service gMSA 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. Saisissez respectivement le nom d'utilisateur, le mot de passe et le domaine de l'utilisateur dans les paires clé-valeur JSON appelées username, password et domainName.

    {"username":"username","password":"passw0rd", "domainName":"example.com"}

  4. Vous devez ajouter les autorisations suivantes sous forme de stratégie en ligne au rôle IAM d'exécution de tâche. Cela permet au démon credentials-fetcher d'accéder au secret Secrets Manager. Remplacez l'exemple MySecret par l'Amazon Resource Name (ARN) de votre secret dans la liste Resource.

    {
  "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 clé KMS 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 l'Amazon Resource Name (ARN) du compartiment Amazon S3 dans le champ credentialSpecs de la définition de 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 sous forme de stratégie en ligne au rôle IAM d'exécution de tâche Amazon ECS.

    {
    "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 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 fichier et chargement de celui-ci sur un Amazon S3

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 sur le site Web Microsoft Learn.

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

Exécutez la AWS CLI commande suivante pour le CredSpec télécharger sur Amazon S3. Remplacez DOC-EXAMPLE-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 "DOC-EXAMPLE-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://DOC-EXAMPLE-BUCKET/ecs-domainless-gmsa-credspec