Fargate で Linux コンテナに gMSA を使用する - Amazon Elastic Container Service

Fargate で Linux コンテナに gMSA を使用する

Amazon ECS は、グループ管理サービスアカウント (gMSA) と呼ばれる特殊なサービスアカウントを使用して、Fargate 上の Linux コンテナの Active Directory 認証をサポートします。

.NET Core アプリケーションなどの Linux ベースのネットワークアプリケーションは Active Directory を使用し、ユーザーとサービス間の認証と認可の管理を容易にできます。この機能は、Active Directory と統合され、ドメインに参加しているサーバー上で実行されるアプリケーションを設計することで利用できます。しかし、Linux コンテナはドメインに参加できないため、gMSA を使用して実行する Linux コンテナを設定する必要があります。

考慮事項

Fargate で Linux コンテナ向けに gMSA を使用する前に、次の点を考慮してください。

  • プラットフォームバージョン 1.4 以降を実行している必要があります。

  • 前提条件を完全に満たすには、ドメインに参加している Windows コンピュータが必要になる場合があります。例えば、PowerShell を使用して Active Directory で gMSA を作成するには、ドメインに参加している Windows コンピュータが必要になる場合があります。RSAT Active Director PowerShell ツールは Windows でのみ使用できます。詳細については、「Active Directory 管理ツールのインストール」を参照してください。

  • ドメインレス gMSA を使用する必要があります。

    Amazon ECS は Active Directory の認証情報仕様ファイル (CredSpec) を使用します。このファイルは、gMSA アカウントコンテキストをコンテナに伝達するために使用される gMSA メタデータを含む認証情報仕様ファイルを使用します。CredSpec ファイルを生成し、Amazon S3 バケットに保存します。

  • 1 つのタスクでサポートできるアクティブディレクトリは 1 つだけです。

前提条件

gMSA を使用する前に、Amazon ECS の Linux コンテナ機能のために必ず以下を完了してください。

  • コンテナがアクセスするリソースを含む Active Directory ドメインを設定します。Amazon ECS は以下の設定をサポートしています。

    • AWS Directory Service Active Directory。AWS Directory Service は、Amazon EC2 でホストされる AWS マネージド Active Directory です。詳細については、「AWS Directory Service 管理ガイド」の「AWS Managed Microsoft AD の開始方法」を参照してください。

    • オンプレミスの Active Directory。Amazon ECS Linux コンテナインスタンスがドメインに参加できることを確認する必要があります。詳細については、「AWS Direct Connect」を参照してください。

  • Active Directory に既存の gMSA アカウントがあり、その gMSA サービスアカウントにアクセスする権限を持つユーザーがいます。詳細については、「ドメインレス gMSA 用に Active Directory ユーザーを作成する」を参照してください。

  • Amazon S3 バケットがある。詳細については、「Amazon S3 ユーザーガイド」の「バケットの作成」を参照してください。

Amazon ECS での gMSA 対応の Linux コンテナの設定

インフラストラクチャを準備する

次のステップは、考慮事項と 1 回実行される設定です。

  • ドメインレス gMSA 用に Active Directory ユーザーを作成する

    ドメインレス gMSAを使用する場合、コンテナはドメインに接続されません。コンテナ上で実行される他のアプリケーションは、Active Directory の認証情報を使用してドメインにアクセスすることはできません。別のドメインを使用するタスクも同じコンテナ上で実行できます。CredSpec ファイルの AWS Secrets Manager にシークレットの名前を指定します。シークレットには、ユーザー名、パスワード、ログイン先のドメインが含まれている必要があります。

    この機能は gMSA support for non-domain-joined container hosts 機能に似ています。Windows の機能の詳細については、Microsoft Learn ウェブサイトの「gMSA アーキテクチャと改善」を参照してください。

    1. Active Directory ドメインでユーザーを設定します。Active Directory のユーザーは、タスクで使用する gMSA サービスアカウントにアクセスするための許可を持っている必要があります。

    2. Active Directory ドメイン名を解決できる VPC とサブネットがあります。DHCP オプションを使用して、Active Directory サービス名を指すドメイン名で VPC を設定します。VPC 向け DHCP オプション設定の詳細については、「Amazon Virtual Private Cloud ユーザーガイド」の「DHCP オプションセットの使用」を参照してください。

    3. AWS Secrets Manager にシークレットを作成します。

    4. 認証情報仕様ファイルを作成します。

許可とシークレットの設定

各アプリケーションおよび各タスク定義ごとに、次のステップを 1 回ずつ実行します。最小特権を認めるというベストプラクティスに従い、ポリシーで使用されるアクセス許可を絞り込むことをお勧めします。これにより、各タスクは必要なシークレットのみを読み取れます。

  1. Active Directory ドメインでユーザーを作成します。Active Directory のユーザーは、タスクで使用する gMSA サービスアカウントにアクセスするための許可を持っている必要があります。

  2. Active Directory ユーザーを作成した後、AWS Secrets Manager でシークレットを作成します。詳細については、「AWS Secrets Manager シークレットを作成する」を参照してください。

  3. ユーザーのユーザー名、パスワード、ドメインを、それぞれ usernamepassworddomainName と呼ばれる JSON キーと値のペアに入力します。

    {"username":"username","password":"passw0rd", "domainName":"example.com"}
  4. 次の権限をインラインポリシーとしてタスク実行 IAM ロールに追加する必要があります。これにより、credentials-fetcher デーモンが Secrets Manager シークレットにアクセスできるようになります。MySecret の例を、Resource リスト内のシークレットの Amazon リソースネーム (ARN) に置き換えます。

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

    独自の KMS キーを使用してシークレットを暗号化する場合は、必要な許可をこのロールに追加し、このロールを AWS KMS キーポリシーに追加する必要があります。

  5. 認証情報の仕様を Amazon S3 バケットに追加します。次に、タスク定義の credentialSpecs フィールドで Amazon S3 バケットの Amazon リソースネーム (ARN) を参照します。

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

    タスクに S3 バケットへのアクセスを許可するには、次のアクセス許可をインラインポリシーとして Amazon ECS タスク実行 IAM ロールに追加します。

    { "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}" ] } ] }

認証情報仕様ファイル

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 を作成して Amazon S3 にアップロードする

CredSpec を作成するには、ドメインに参加している Windows コンピューター上の CredSpec PowerShell モジュールを使用します。Microsoft Learn Web サイトの「認証情報の仕様を作成する」のステップに従います。

認証情報仕様ファイルを作成したら、Amazon S3 バケットにアップロードします。コマンドを実行しているコンピューターまたは環境に CredSpec ファイルをコピーします。

次の AWS CLI コマンドを実行し、Amazon S3 に CredSpec をアップロードします。amzn-s3-demo-bucket をお使いの Amazon S3 バケットの名前に置き換えます。ファイルは任意のバケットと場所にオブジェクトとして保存できますが、タスク実行ロールにアタッチするポリシーでそのバケットと場所へのアクセスを許可する必要があります。

PowerShell については、次のコマンドを実行します。

$ Write-S3Object -BucketName "amzn-s3-demo-bucket" -Key "ecs-domainless-gmsa-credspec" -File "gmsa-cred-spec.json"

次の AWS CLI コマンドでは、sh および互換性のあるシェルで使用されるバックスラッシュ継続文字を使用します。

$ aws s3 cp gmsa-cred-spec.json \ s3://amzn-s3-demo-bucket/ecs-domainless-gmsa-credspec