Amazon ECS에서 EC2 Linux 컨테이너에 대해 gMSA 사용 - Amazon Elastic Container Service

Amazon ECS에서 EC2 Linux 컨테이너에 대해 gMSA 사용

Amazon ECS는 그룹 관리형 서비스 계정(gMSA)이라는 특수한 종류의 서비스 계정을 통해 EC2의 Linux 컨테이너에 대한 Active Directory 인증을 지원합니다.

.NET Core 애플리케이션과 같은 Linux 기반 네트워크 애플리케이션은 Active Directory를 사용하여 사용자와 서비스 간의 인증 및 권한 부여 관리를 용이하게 할 수 있습니다. Active Directory와 통합되고 도메인 가입된 서버에서 실행되는 애플리케이션을 설계하여 이 기능을 사용할 수 있습니다. 하지만 Linux 컨테이너는 도메인에 가입할 수 없으므로 gMSA로 실행할 Linux 컨테이너를 구성해야 합니다.

gMSA로 실행되는 Linux 컨테이너는 컨테이너의 호스트 Amazon EC2 인스턴스에서 실행되는 credentials-fetcher 대몬(daemon)을 사용합니다. 즉, 대몬(daemon)은 Active Directory 도메인 컨트롤러에서 gMSA 보안 인증을 검색한 다음 이러한 보안 인증을 컨테이너 인스턴스로 전송합니다. 서비스 계정에 대한 자세한 내용은 Microsoft Learn 웹 사이트에서 Create gMSAs for Windows containers를 참조하세요.

고려 사항

Linux 컨테이너에 gMSA를 사용하기 전에 다음 사항을 고려하세요.

  • 컨테이너가 EC2에서 실행되는 경우 Windows 컨테이너와 Linux 컨테이너에 gMSA를 사용할 수 있습니다. Fargate의 Linux 컨테이너에서 gMSA를 사용하는 방법에 대한 자세한 내용은 Fargate의 Linux 컨테이너에서 gMSA 사용 섹션을 참조하세요.

  • 사전 조건을 완료하려면 도메인에 가입된 Windows 컴퓨터가 필요할 수 있습니다. 예를 들어, PowerShell을 사용하여 Active Directory에서 gMSA를 생성하려면 도메인에 가입된 Windows 컴퓨터가 필요할 수 있습니다. RSAT Active Director PowerShell 도구는 Windows에서만 사용할 수 있습니다. 자세한 내용은 Installing the Active Directory administration tools를 참조하세요.

  • 도메인 없는 gMSA각 인스턴스를 단일 도메인에 가입 중에서 선택할 수 있습니다. 도메인 없는 gMSA를 사용하면 컨테이너 인스턴스는 도메인에 가입되지 않고, 인스턴스의 다른 애플리케이션은 보안 인증을 사용하여 도메인에 액세스할 수 없고, 다른 도메인에 가입하는 작업은 동일한 인스턴스에서 실행될 수 있습니다.

    그런 다음 CredSpec 및 선택적으로 도메인 없는 gMSA에 대한 Active Directory 사용자 보안 인증으로 데이터 스토리지를 선택합니다.

    Amazon ECS는 Active Directory 보안 인증 사양 파일(CredSpec)을 사용합니다. 이 파일은 gMSA 계정 컨텍스트를 컨테이너에 전파하는 데 사용되는 gMSA 메타데이터를 포함합니다. CredSpec 파일을 생성하고 다음 표의 컨테이너 인스턴스의 운영 체제별 CredSpec 스토리지 옵션 중 하나에 저장합니다. 도메인 없는 방법을 사용하려면 CredSpec 파일의 선택적 섹션에서 다음 표의 컨테이너 인스턴스의 운영 체제별 domainless user credentials스토리지 옵션 중 하나에 보안 인증을 지정할 수 있습니다.

    스토리지 위치 Linux Windows
    Amazon Simple Storage Service(S3) CredSpec CredSpec
    AWS Secrets Manager 도메인 없는 사용자 보안 인증 도메인 없는 사용자 보안 인증
    Amazon EC2 Systems Manager Parameter Store CredSpec CredSpec, 도메인 없는 사용자 보안 인증
    로컬 파일 N/A CredSpec

사전 조건

Amazon ECS에서 Linux 컨테이너 기능에 gMSA를 사용하려면 먼저 다음 사항을 충족해야 합니다.

  • 컨테이너에서 액세스할 리소스를 포함하는 Active Directory 도메인을 설정합니다. Amazon ECS는 다음 설정을 지원합니다.

    • AWS Directory Service Active Directory. AWS Directory Service는 Amazon EC2에 호스트되는 AWS 관리형 Active Directory입니다. 자세한 내용은 AWS Directory Service 관리 안내서AWS 관리형 Microsoft AD 시작하기를 참조하세요.

    • 온프레미스 Active Directory. Amazon ECS Linux 컨테이너 인스턴스가 도메인에 가입할 수 있도록 해야 합니다. 자세한 내용은 AWS Direct Connect 단원을 참조하십시오.

  • Active Directory에 기존 gMSA 계정이 있습니다. 자세한 내용은 Amazon ECS에서 EC2 Linux 컨테이너에 대해 gMSA 사용 단원을 참조하십시오.

  • Amazon ECS Linux 컨테이너 인스턴스에 credentials-fetcher 대몬(daemon)을 설치하여 실행하고 있습니다. 또한 Active Directory에 인증하기 위해 credentials-fetcher 대몬(daemon)에 초기 보안 인증 세트를 추가했습니다.

    참고

    credentials-fetcher 대몬(daemon)은 Amazon Linux 2023 및 Fedora 37 이상에서만 사용할 수 있습니다. Amazon Linux 2에서는 대몬(daemon)을 사용할 수 없습니다. 자세한 내용은 GitHub의 aws/credentials-fetcher를 참조하세요.

  • credentials-fetcher 대몬(daemon)을 Active Directory에 인증하기 위해 보안 인증을 설정합니다. 보안 인증은 gMSA 계정에 액세스할 수 있는 Active Directory 보안 그룹의 멤버여야 합니다. 인스턴스를 도메인에 가입시킬지, 아니면 도메인 없는 gMSA를 사용할지 결정합니다.에 에는 여러 옵션이 있습니다.

  • 필요한 IAM 권한을 추가했습니다. 필요한 권한은 초기 보안 인증 및 보안 인증 사양 저장을 위해 선택하는 방법에 따라 달라집니다.

    • 초기 보안 인증에 도메인 없는 gMSA를 사용하는 경우 AWS Secrets Manager에 대한 IAM 권한이 작업 실행 역할에 필요합니다.

    • 보안 인증 사양을 SSM Parameter Store에 저장하는 경우 Amazon EC2 Systems Manager Parameter Store에 대한 IAM 권한이 작업 실행 역할에 필요합니다.

    • 보안 인증 사양을 Amazon S3에 저장하는 경우에는 Amazon Simple Storage Service에 대한 IAM 권한이 작업 실행 역할에 필요합니다.

Amazon ECS에서 gMSA 지원 Linux 컨테이너 설정

인프라 준비

다음 단계는 고려 사항과 한 번 수행하는 설정입니다. 이 단계를 완료하면 컨테이너 인스턴스 생성을 자동화하여 이 구성을 재사용할 수 있습니다.

초기 보안 인증을 제공하는 방법을 결정하고 재사용 가능한 EC2 시작 템플릿에 EC2 사용자 데이터를 구성하여 credentials-fetcher 대몬(daemon)을 설치합니다.

  1. 인스턴스를 도메인에 가입시킬지, 아니면 도메인 없는 gMSA를 사용할지 결정합니다.
    • EC2 인스턴스를 Active Directory 도메인에 가입

      • 사용자 데이터로 인스턴스 가입

        EC2 시작 템플릿의 EC2 사용자 데이터에 Active Directory 도메인에 가입하는 단계를 추가합니다. 여러 Amazon EC2 Auto Scaling 그룹에서 동일한 시작 템플릿을 사용할 수 있습니다.

        Fedora Docs의 Joining an Active Directory or FreeIPA domain 단계를 사용할 수 있습니다.

    • 도메인 없는 gMSA를 위한 Active Directory 사용자 만들기

      credentials-fetcher 대몬(daemon)에는 도메인 없는 gMSA라는 기능이 있습니다. 이 기능에는 도메인이 필요하지만 EC2 인스턴스를 도메인에 가입시킬 필요는 없습니다. 도메인 없는 gMSA를 사용하면 컨테이너 인스턴스는 도메인에 가입되지 않고, 인스턴스의 다른 애플리케이션은 보안 인증을 사용하여 도메인에 액세스할 수 없고, 다른 도메인에 가입하는 작업은 동일한 인스턴스에서 실행될 수 있습니다. 대신 AWS Secrets Manager에서 CredSpec 파일에 보안 암호의 이름을 입력합니다. 보안 암호에는 사용자 이름, 암호 및 로그인할 도메인이 포함되어야 합니다.

      이 기능은 Linux 및 Windows 컨테이너에서 지원되며 사용할 수 있습니다.

      이 기능은 gMSA support for non-domain-joined container hosts 기능과 유사합니다. Windows 기능에 대한 자세한 내용은 Microsoft Learn 웹 사이트의 gMSA architecture and improvements를 참조하세요.

      1. Active Directory 도메인에서 사용자를 만듭니다. Active Directory의 사용자는 작업에서 사용하는 gMSA 서비스 계정에 액세스할 수 있는 권한이 있어야 합니다.

      2. Active Directory에서 사용자를 만든 후 AWS Secrets Manager에서 비밀을 생성합니다. 자세한 내용은 AWS Secrets Manager 보안 암호 생성을 참조하세요.

      3. 사용자의 사용자 이름, 암호 및 도메인을 각각 username, passworddomainName이라는 JSON 키-값 쌍에 입력합니다.

        {"username":"username","password":"passw0rd", "domainName":"example.com"}
      4. 서비스 계정의 CredSpec 파일에 구성을 추가합니다. 추가 HostAccountConfig에는 Secrets Manager에 있는 보안 암호의 Amazon 리소스 이름(ARN)이 포함됩니다.

        Windows에서 PluginGUID는 다음 예제 코드 조각의 GUID와 일치해야 합니다. Linux에서는 PluginGUID가 무시됩니다. 예제에서 MySecret은 보안 암호의 Amazon 리소스 이름 (ARN)으로 바꿉니다.

        "ActiveDirectoryConfig": { "HostAccountConfig": { "PortableCcgVersion": "1", "PluginGUID": "{859E1386-BDB4-49E8-85C7-3070B13920E1}", "PluginInput": { "CredentialArn": "arn:aws:secretsmanager:aws-region:111122223333:secret:MySecret" } }
      5. 도메인 없는 gMSA 기능을 사용하려면 작업 실행 역할에 추가 권한이 필요합니다. (선택 사항) 도메인 없는 gMSA 보안 암호 단계를 따릅니다.

  2. 인스턴스 구성 및 credentials-fetcher 대몬(daemon) 설치

    EC2 시작 템플릿에서 사용자 데이터 스크립트를 사용하여 credentials-fetcher 대몬(daemon)을 설치할 수 있습니다. 다음 예제에서는 두 가지 유형의 사용자 데이터인 cloud-config YAML 또는 bash 스크립트를 보여줍니다. 이러한 예제는 Amazon Linux 2023(AL2023)용입니다. MyCluster를 이러한 인스턴스를 조인할 Amazon ECS 클러스터의 이름으로 바꿉니다.

    • 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 스크립트

      bash 스크립트에 더 익숙하고 /etc/ecs/ecs.config에 쓸 변수가 여러 개인 경우 다음 heredoc 형식을 사용합니다. 이 형식은 cat으로 시작하는 라인과 EOF 사이의 모든 항목을 구성 파일에 작성합니다.

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

    credentials-fetcher 대몬(daemon)에 대한 선택적 구성 변수를 /etc/ecs/ecs.config에서 설정할 수 있습니다. 위 예제와 유사한 YAML 블록 또는 heredoc의 사용자 데이터에 변수를 설정하는 것이 좋습니다. 이렇게 하면 파일을 여러 번 편집하여 발생할 수 있는 부분 구성 문제를 방지할 수 있습니다. ECS 에이전트 구성에 대한 자세한 내용은 GitHub의 Amazon ECS Container Agent를 참조하세요.

    • 또는, 소켓을 다른 위치로 이동하도록 credentials-fetcher 대몬(daemon) 구성을 변경하는 경우 CREDENTIALS_FETCHER_HOST 변수를 사용할 수 있습니다.

권한 및 보안 암호 설정

각 애플리케이션과 각 작업 정의에 대해 다음 단계를 한 번 수행합니다. 최소 권한을 부여하는 모범 사례를 따르고 정책에서 사용되는 권한의 범위를 좁히는 것이 좋습니다. 이렇게 하면 각 작업에서 필요한 보안 암호만 읽을 수 있습니다.

  1. (선택 사항) 도메인 없는 gMSA 보안 암호

    인스턴스가 도메인에 가입되지 않은 도메인 없는 방법을 사용하는 경우 이 단계를 따릅니다.

    작업 실행 IAM 역할에 다음 권한을 인라인 정책으로 추가해야 합니다. 이렇게 하면 credentials-fetcher 대몬(daemon)이 Secrets Manager 보안 암호에 액세스할 수 있게 됩니다. MySecret 예제를 Resource 목록에 있는 보안 암호의 Amazon 리소스 이름(ARN)으로 바꿉니다.

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

    자체 KMS 키를 사용하여 보안 암호를 암호화하는 경우 이 역할에 필요한 권한을 추가하고 이 역할을 AWS KMS 키 정책에 추가해야 합니다.

  2. SSM Parameter Store 또는 S3를 사용하여 CredSpec를 저장할지 결정

    Amazon ECS에서는 작업 정의의 credentialSpecs 필드에서 파일 경로를 참조하는 다음과 같은 방법을 지원합니다.

    인스턴스를 단일 도메인에 가입시키는 경우 문자열에서 ARN 시작 부분에 credentialspec: 접두사를 사용합니다. 도메인 없는 gMSA를 사용하는 경우에는 credentialspecdomainless:를 사용합니다.

    CredSpec에 대한 자세한 내용은 보안 인증 사양 파일 섹션을 참조하세요.

    • Amazon S3 버킷

      보안 인증 사양을 Amazon S3 버킷에 추가합니다. 그런 다음 작업 정의의 credentialSpecs 필드에서 Amazon S3 버킷의 Amazon 리소스 이름(ARN)을 참조합니다.

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

      또한 작업에 Amazon S3 버킷에 대한 액세스 권한을 부여하려면 Amazon ECS 작업 실행 IAM 역할에 다음 권한을 인라인 정책으로 추가합니다.

      { "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}" ] } ] }
    • SSM Parameter Store 파라미터

      보안 인증 사양을 SSM Parameter Store 파라미터에 추가합니다. 그런 다음 작업 정의의 credentialSpecs 필드에서 SSM Parameter Store 파라미터의 Amazon 리소스 이름(ARN)을 참조합니다.

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

      또한 작업에 SSM Parameter Store 파라미터에 대한 액세스 권한을 부여하려면 Amazon ECS 작업 실행 IAM 역할에 다음 권한을 인라인 정책으로 추가합니다.

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

보안 인증 사양 파일

Amazon ECS는 Active Directory 보안 인증 사양 파일(CredSpec)을 사용합니다. 이 파일은 gMSA 계정 컨텍스트를 Linux 컨테이너에 전파하는 데 사용되는 gMSA 메타데이터를 포함합니다. CredSpec를 생성하여 작업 정의의 credentialSpecs 필드에서 참조합니다. CredSpec 파일에는 보안 암호가 포함되어 있지 않습니다.

다음은 예 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" } } } }
CredSpec 생성

도메인에 가입된 Windows 컴퓨터에서 CredSpec PowerShell 모듈을 사용하여 CredSpec를 생성합니다. Microsoft Learn 웹 사이트에서 Create a credential spec의 단계를 따릅니다.