Utilisation gMSA pour EC2 Linux conteneurs sur Amazon ECS

Décidez si vous souhaitez joindre les instances au domaine ou utiliser le mode sans domaine gMSA.

• 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 FreeIPA domaine dans les documents Fedora.

• Créer un utilisateur Active Directory pour domainless gMSA

  Le credentials-fetcher démon possède une fonctionnalité appelée «  sans domaine » gMSA. Cette fonctionnalité nécessite un domaine, mais il n'est pas nécessaire que l' EC2instance soit jointe au domaine. En utilisant le mode sans domaine gMSA, 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. Au lieu de cela, vous indiquez le nom d'un secret AWS Secrets Manager dans le 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 prise en charge et peut être utilisée avec les conteneurs Linux et Windows.

  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. 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. Créez un secret dans AWS Secrets Manager, après avoir créé l'utilisateur dans Active Directory. Pour plus d'informations, consultez la section Création d'un AWS Secrets Manager secret.

  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. Ajoutez une configuration au CredSpec fichier pour le compte de service. La HostAccountConfig supplémentaire contient l'Amazon Resource Name (ARN) du secret dans Secrets Manager.

     Sous Windows, le PluginGUID doit correspondre au GUID indiqué dans l'exemple de code suivant. Sous Linux, le PluginGUID est ignoré. Remplacez MySecret par l'exemple avec l'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. Le sans domaine gMSAla fonctionnalité nécessite des autorisations supplémentaires dans le rôle d'exécution des tâches. Suivez l'étape (Facultatif) sans domaine gMSA secret.

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 or bash script. Ces exemples concernent Amazon Linux 2023 (AL2023). Remplacez MyCluster par le nom du cluster Amazon ECS que 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-fetcher && systemctl enable credentials-fetcher"

• bash script

  Si vous êtes plus à l'aise avec bash pour les scripts contenant plusieurs variables dans lesquelles écrire/etc/ecs/ecs.config, utilisez le heredoc format 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-fetcher && 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 bloc YAML ou heredoc de 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'agent ECS, consultez Amazon ECS Container Agent on GitHub.

(Facultatif) sans domaine gMSA secret

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 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:ssm:aws-region:111122223333:secret:MySecret"
            ]
        }
    ]
}

Décidez si vous utilisez le magasin de paramètres SSM ou S3 pour stocker le CredSpec

Amazon ECS permet de référencer le chemin du fichier dans le champ credentialSpecs d'une définition de tâche.

Si vous joignez les instances à un seul domaine, utilisez le préfixe credentialspec: au début de l'ARN dans la chaîne. Si vous utilisez le mode sans domaine gMSA, puis utilisezcredentialspecdomainless:.

Pour plus d'informations sur le CredSpec, voir 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 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: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'informations d'identification à un paramètre de SSM Parameter Store. Référencez ensuite l'Amazon Resource Name (ARN) du paramètre de SSM Parameter Store dans le champ credentialSpecs de la définition de tâche.

  {
      "family": "",
      "executionRoleArn": "",
      "containerDefinitions": [
          {
              "name": "",
              ...
              "credentialSpecs": [
                  "credentialspecdomainless:arn:aws:ssm:aws-region:111122223333:parameter/parameter_name"
              ],
              ...
          }
      ],
      ...
  }

  Pour permettre à vos tâches d'accéder au paramètre de SSM Parameter Store, 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": [
          {
              "Effect": "Allow",
              "Action": [
                  "ssm:GetParameters"
              ],
              "Resource": [
                  "arn:aws:ssm:aws-region:111122223333:parameter/parameter_name"
              ]
          }
      ]
  }