Uso de gMSA para contenedores de EC2 Linux en Amazon ECS - Amazon Elastic Container Service

Uso de gMSA para contenedores de EC2 Linux en Amazon ECS

Amazon ECS admite la autenticación de Active Directory para contenedores de Linux en EC2 con un tipo especial de cuenta de servicio denominada cuenta de servicio administrada de grupo (gMSA).

Las aplicaciones de red basadas en Linux, como las aplicaciones .NET Core, pueden utilizar Active Directory para facilitar la administración de autorizaciones y autenticación entre usuarios y servicios. Puede utilizar esta característica diseñando aplicaciones que se integren con Active Directory y se ejecuten en servidores unidos a un dominio. Sin embargo, dado que los contenedores de Linux no se pueden unir a un dominio, debe configurar un contenedor de Linux para que se ejecute con gMSA.

Un contenedor de Linux que se ejecuta con gMSA depende del daemon credentials-fetcher que se ejecuta en la instancia de Amazon EC2 del host del contenedor. Es decir, el daemon recupera las credenciales de la gMSA del controlador de dominio de Active Directory y, a continuación, las transfiere a la instancia de contenedor. Para obtener más información sobre las cuentas de servicio, consulte Crear gMSAs para contenedores de Windows en el sitio web de Microsoft Learn.

Consideraciones

Tenga en cuenta lo siguiente antes de usar una gMSA para contenedores de Linux:

  • Si sus contenedores se ejecutan en EC2, puede utilizar gMSA para contenedores de Windows y de Linux. Para obtener información sobre cómo utilizar el contenedor gMSA de Linux en Fargate, consulte Uso de gMSA para contenedores de Linux en Fargate.

  • Puede que necesite una computadora con Windows unida al dominio para cumplir los requisitos previos. Por ejemplo, puede que necesite una computadora con Windows que esté unida al dominio para crear la gMSA en Active Directory con PowerShell. Las herramientas de PowerShell en Active Directory RSAT solo están disponibles para Windows. Para obtener más información, consulte Instalar las herramientas de administración de Active Directory.

  • Puede elegir entre gMSA sin dominio o unir cada instancia a un único dominio. Al usar una gMSA sin dominio, la instancia de contenedor no se une al dominio, las demás aplicaciones de la instancia no pueden utilizar las credenciales para acceder al dominio y las tareas que unen diferentes dominios se pueden ejecutar en la misma instancia.

    A continuación, seleccione el almacenamiento de datos para las CredSpec y, de forma opcional, para las credenciales de usuario de Active Directory para gMSA sin dominio.

    Amazon ECS utiliza un archivo de especificaciones de credenciales de Active Directory (CredSpec). Este archivo contiene los metadatos de gMSA utilizados para propagar el contexto de la cuenta de gMSA al contenedor. Genera el archivo de CredSpec y, a continuación, lo almacena en una de las opciones de almacenamiento de CredSpec de la siguiente tabla, específica del sistema operativo de las instancias de contenedor. Para usar el método sin dominio, en una sección opcional del archivo de CredSpec se pueden especificar las credenciales de una de las opciones de almacenamiento domainless user credentials de la siguiente tabla, específicas del sistema operativo de las instancias de contenedor.

    Opciones de almacenamiento de datos de gMSA por sistema operativo
    Ubicación de almacenamiento Linux Windows
    Amazon Simple Storage Service CredSpec CredSpec
    AWS Secrets Manager credenciales de usuario sin dominio credenciales de usuario sin dominio
    Parameter Store de Amazon EC2 Systems Manager CredSpec CredSpec, credenciales de usuario sin dominio
    Archivo local N/A CredSpec

Requisitos previos

Antes de utilizar la característica de gMSA para contenedores de Linux con Amazon ECS, asegúrese de completar lo siguiente:

  • Configure un dominio de Active Directory con los recursos a los que desea que accedan sus contenedores. Amazon ECS admite las siguientes configuraciones:

    • Un AWS Directory Service Active Directory. AWS Directory Service es un Active Directory administrado por AWS y alojado en Amazon EC2. Para obtener más información, consulte Introducción a Microsoft AD administrado por AWS en la Guía de administración de AWS Directory Service.

    • Un Active Directory en las instalaciones. Debe asegurarse de que la instancia de contenedor de Linux de Amazon ECS pueda unirse al dominio. Para obtener más información, consulte AWS Direct Connect.

  • Tiene una cuenta de gMSA existente en Active Directory. Para obtener más información, consulte Uso de gMSA para contenedores de EC2 Linux en Amazon ECS.

  • Instaló y está ejecutando el credentials-fetcher daemon en una instancia de contenedor Linux de Amazon ECS. También agregó un conjunto inicial de credenciales al credentials-fetcher daemon para autenticarse en Active Directory.

    nota

    El credentials-fetcher daemon solo está disponible para Amazon Linux 2023 y Fedora 37 y versiones posteriores. El daemon no está disponible para Amazon Linux 2. Para obtener más información, consulte aws/credentials-fetcher en GitHub.

  • Configuró las credenciales para que el credentials-fetcher daemon se autentique en Active Directory. Las credenciales deben ser miembros del grupo de seguridad de Active Directory que tenga acceso a la cuenta de gMSA. Hay varias opciones en Decida si quiere unir las instancias al dominio o usar gMSA sin dominio..

  • Agregó los permisos necesarios de IAM. Los permisos necesarios dependen de los métodos que elija para las credenciales iniciales y para almacenar la especificación de las credenciales:

    • Si utiliza las credenciales iniciales sin dominio de gMSA, se requieren permisos de IAM para AWS Secrets Manager en el rol de ejecución de tareas.

    • Si almacena la especificación de credenciales en SSM Parameter Store, se requieren permisos de IAM para Parameter Store de Amazon EC2 Systems Manager en el rol de ejecución de la tarea.

    • Si almacena la especificación de credenciales en Amazon S3, se requieren permisos de IAM para Amazon Simple Storage Service en el rol de ejecución de tareas.

Configuración de contenedores de Linux compatibles con gMSA en Amazon ECS

Preparar la infraestructura

Los siguientes pasos son consideraciones y la configuración que se realizan una vez. Después de completar estos pasos, puede automatizar la creación de instancias de contenedores para reutilizar esta configuración.

Decida cómo se proporcionan las credenciales iniciales y configure los datos de usuario de EC2 en una plantilla de lanzamiento de EC2 reutilizable para instalar el credentials-fetcher daemon.

  1. Decida si quiere unir las instancias al dominio o usar gMSA sin dominio.
    • Unir instancias de EC2 al dominio de Active Directory

      • Una las instancias por datos de usuario.

        Agregue los pasos para unir el dominio de Active Directory a sus datos de usuario de EC2 en una plantilla de lanzamiento de EC2. Varios grupos de Amazon EC2 Auto Scaling pueden utilizar la misma plantilla de lanzamiento.

        Puede seguir estos pasos Unirse a un dominio FreeIPA o a Active Directory en los documentos de Fedora.

    • Hacer que un usuario de Active Directory sea una gMSA sin dominio

      El credentials-fetcher daemon tiene una característica que se denomina gMSA sin dominio. Esta característica requiere un dominio, pero no es necesario unir la instancia EC2 al dominio. Al usar una gMSA sin dominio, la instancia de contenedor no se une al dominio, las demás aplicaciones de la instancia no pueden utilizar las credenciales para acceder al dominio y las tareas que unen diferentes dominios se pueden ejecutar en la misma instancia. En su lugar, debe proporcionar el nombre de un secreto en AWS Secrets Manager en el archivo de CredSpec. El secreto debe contener un nombre de usuario, una contraseña y el dominio para iniciar sesión.

      Esta característica es compatible y se puede utilizar con contenedores de Linux y Windows.

      Esta característica es similar a la característica gMSA support for non-domain-joined container hosts. Para obtener más información sobre la característica de Windows, consulte Arquitectura y mejoras de gMSA en el sitio web de Microsoft Learn.

      1. Cree un usuario en el dominio de Active Directory. El usuario de Active Directory debe tener permiso para acceder a las cuentas de servicio de gMSA que utilice en las tareas.

      2. Cree un secreto en AWS Secrets Manager después de crear el usuario en Active Directory. Para obtener más información, consulte Crear un secreto de AWS Secrets Manager.

      3. Introduzca el nombre de usuario, la contraseña y el dominio en pares clave-valor de JSON denominados username, password y domainName, respectivamente.

        {"username":"username","password":"passw0rd", "domainName":"example.com"}
      4. Agregue la configuración al archivo de CredSpec de la cuenta de servicio. La HostAccountConfig adicional contiene el nombre de recurso de Amazon (ARN) del secreto de Secrets Manager.

        En Windows, el PluginGUID debe coincidir con el GUID del siguiente fragmento de ejemplo. En Linux, se omite el PluginGUID. Reemplace MySecret con un ejemplo del nombre de recurso de Amazon (ARN) de su secreto.

        "ActiveDirectoryConfig": { "HostAccountConfig": { "PortableCcgVersion": "1", "PluginGUID": "{859E1386-BDB4-49E8-85C7-3070B13920E1}", "PluginInput": { "CredentialArn": "arn:aws:secretsmanager:aws-region:111122223333:secret:MySecret" } }
      5. La característica de gMSA sin dominio necesita permisos adicionales en el rol de ejecución de tareas. Siga el paso (Opcional) secreto de gMSA sin dominio.

  2. Configurar las instancias e instalar el credentials-fetcher daemon

    Puede instalar el credentials-fetcher daemon con un script de datos de usuario en su plantilla de lanzamiento de EC2. Los siguientes ejemplos muestran dos tipos de datos de usuario, cloud-config YAML o script de bash. Estos ejemplos son para Amazon Linux 2023 (AL2023). Reemplace MyCluster por el nombre del clúster de Amazon ECS al que desea que se unan estas instancias.

    • 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"
    • bash script

      Si se siente más cómodo con scripts de bash y tiene distintas variables en las que escribir /etc/ecs/ecs.config, utilice el siguiente formato de heredoc. Este formato escribe todo entre las líneas que comienzan por cat y EOF en el archivo de configuración.

      #!/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

    Hay variables de configuración opcionales para el credentials-fetcher daemon que puede configurar en /etc/ecs/ecs.config. Se recomienda configurar las variables de los datos de usuario en el bloque YAML o en heredoc, de forma similar a los ejemplos anteriores. De este modo, se evitan los problemas de configuración parcial que pueden producirse al editar un archivo varias veces. Para obtener más información sobre la configuración del agente de ECS, consulte Agente de contenedor de Amazon ECS en GitHub.

    • De forma opcional, puede usar la variable CREDENTIALS_FETCHER_HOST si cambia la configuración del credentials-fetcher daemon para mover el socket a otra ubicación.

Configuración de permisos y secretos

Realice los siguientes pasos una vez para cada aplicación y cada definición de tarea. Recomendamos utilizar la práctica recomendada de concesión de privilegios mínimos y reducir los permisos que se utilizan en la política. De esta forma, cada tarea solo puede leer los secretos que necesita.

  1. (Opcional) secreto de gMSA sin dominio

    Si utiliza el método sin dominio en el que la instancia no está unida al dominio, siga este paso.

    También debe agregar los siguientes permisos como una política en línea al rol de IAM de ejecución de tareas. De ese modo, el credentials-fetcher daemon tendrá acceso al secreto de Secrets Manager. Reemplace el ejemplo de MySecret con el nombre de recurso de Amazon (ARN) de su secreto en la lista de Resource.

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

    Si utiliza su propia clave de KMS para cifrar el secreto, debe agregar los permisos necesarios a este rol y agregar este rol a la política de claves de AWS KMS.

  2. Decidir si utilizar SSM Parameter Store o S3 para almacenar el CredSpec

    Amazon ECS admite las siguientes formas de hacer referencia a la ruta de archivo en el campo credentialSpecs de una definición de tarea.

    Si une las instancias a un solo dominio, utilice el prefijo credentialspec: al principio del ARN de la cadena. Si utiliza la gMSA sin dominio, utilice credentialspecdomainless:.

    Para obtener más información sobre CredSpec, consulte Archivo de especificaciones de credenciales.

    • Bucket de Amazon S3

      Agregue la especificación de credenciales a un bucket de Amazon S3. A continuación, haga referencia al nombre de recurso de Amazon (ARN) del bucket de Amazon S3 en el campo credentialSpecs de la definición de tareas.

      { "family": "", "executionRoleArn": "", "containerDefinitions": [ { "name": "", ... "credentialSpecs": [ "credentialspecdomainless:arn:aws:s3:::${BucketName}/${ObjectName}" ], ... } ], ... }

      Para que las tareas tengan acceso al bucket de S3, agregue los siguientes permisos como una política en línea al rol de IAM de ejecución de tareas de Amazon ECS.

      { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor", "Effect": "Allow", "Action": [ "s3:Get*", "s3:List*" ], "Resource": [ "arn:aws:s3:::DOC-EXAMPLE-BUCKET", "arn:aws:s3:::DOC-EXAMPLE-BUCKET/{object}" ] } ] }
    • Parámetro de Parameter Store de SSM

      Agregue la especificación de credenciales a un parámetro de SSM Parameter Store. A continuación, haga referencia al nombre de recurso de Amazon (ARN) del parámetro de SSM Parameter Store en el campo credentialSpecs de la definición de tareas.

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

      Para que las tareas tengan acceso al parámetro de SSM Parameter Store, agregue los siguientes permisos como una política en línea al rol de IAM de ejecución de tareas de Amazon ECS.

      { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "ssm:GetParameters" ], "Resource": [ "arn:aws:ssm:aws-region:111122223333:parameter/parameter_name" ] } ] }

Archivo de especificaciones de credenciales

Amazon ECS utiliza un archivo de especificaciones de credenciales de Active Directory (CredSpec). Este archivo contiene los metadatos de gMSA utilizados para propagar el contexto de la cuenta de gMSA al contenedor de Linux. Genere las CredSpec y haga referencia a ellas en el campo credentialSpecs de la definición de tareas. El archivo de CredSpec no contiene ningún secreto.

A continuación se muestra un ejemplo de un archivo 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" } } } }
Creación de un CredSpec

Cree unas CredSpec utilizando el módulo PowerShell de CredSpec en una computadora con Windows que esté unida al dominio. Siga los pasos que se indican en Crear una especificación de credenciales en el sitio web de Microsoft Learn.