Utilisation gMSA pour les EC2 Linux conteneurs sur Amazon ECS - 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 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 sur le site Web de Microsoft Learn.

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'exploitation
    Emplacement 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émon credentials-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-fetcher on. 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.

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

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

      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. 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, le PluginGUID est ignoré. MySecretRemplacez-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"
            }
        }

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

  2. 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). MyClusterRemplacez-le par le nom du ECS cluster Amazon auquel vous souhaitez que ces instances rejoignent.

    • cloud-config YAML
      Content-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 format heredoc suivant. Ce format écrit tout entre les lignes commençant par cat et EOF 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 de heredoc 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 Agent on GitHub.

    • Vous pouvez éventuellement utiliser la variable CREDENTIALS_FETCHER_HOST si vous modifiez la configuration du démon credentials-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.

  1. (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'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:ssm: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.

  2. 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, utilisez credentialspecdomainless:.

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