Amazon ECS タスクでの IAM ロールの使用 - Amazon Elastic Container Service
タスク実行ロールAmazon EC2 コンテナインスタンスのロールサービスにリンクされたロールRecommendations

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Amazon ECS タスクでの IAM ロールの使用

タスクに IAM ロールを割り当てることをお勧めします。そのロールは、実行されている Amazon EC2 インスタンスのロールと区別できます。各タスクにロールを割り当てることは、権限の最小化アクセスの原則と一致し、アクションとリソースをより細かく制御できます。

タスクに IAM ロールを割り当てるときは、各タスクが EC2 インスタンスで使用する IAM ロールとは異なる IAM ロールを引き受けることができるように、次の信頼ポリシーを使用する必要があります。この方法では、タスクが EC2 インスタンスのロールを継承しません。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "ecs-tasks.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

タスク定義にタスクロールを追加すると、Amazon ECS コンテナエージェントは、一意の認証情報 ID を持つトークンを自動的に作成します（12345678-90ab-cdef-1234-567890abcdef) を選択します。このトークンとロール認証情報は、エージェントの内部キャッシュに追加されます。エージェントは、環境変数AWS_CONTAINER_CREDENTIALS_RELATIVE_URIをクレデンシャル ID の URI でコンテナー内に格納します (たとえば、/v2/credentials/12345678-90ab-cdef-1234-567890abcdef).

このワークフローは、Amazon ECS コンテナエージェントが認証情報をキャッシュするときに関係するプロセスを示します。これらの資格情報は、タスク定義で定義されているタスクロールによって決定されます。

Amazon ECS コンテナエージェントの IP アドレスに環境変数を追加し、curlコマンドを実行します。

curl 192.0.2.0$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI

予想される出力は次のようになります。

{
	"RoleArn": "arn:aws:iam::123456789012:role/SSMTaskRole-SSMFargateTaskIAMRole-DASWWSF2WGD6",
	"AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
	"SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
	"Token": "IQoJb3JpZ2luX2VjEEM/Example==",
	"Expiration": "2021-01-16T00:51:53Z"
}

新しいバージョンのAWSSDK は、これらの認証情報を自動的にAWS_CONTAINER_CREDENTIALS_RELATIVE_URI作成時の環境変動AWSAPI コール。

出力には、アプリケーションがアクセスするために使用するシークレットアクセスキー ID とシークレットキーからなるアクセスキーペアが含まれます。AWSリソースの使用料金を見積もることができます。また、トークンも含まれています。AWSが、認証情報が有効であることを確認します。既定では、タスクロールを使用してタスクに割り当てられた資格情報は 6 時間有効です。その後、Amazon ECS コンテナエージェントによって自動的に回転されます。

タスク実行ロール

タスク実行ロールは、Amazon ECS コンテナエージェントに、特定のAWSAPI アクションをユーザーに代わって実行します。たとえば、使用する場合AWS Fargateでは、Fargate には、Amazon ECR からイメージを取得し、CloudWatch Logs にログを書き込むことができる IAM ロールが必要です。IAM ロールは、タスクがAWS Secrets Managerなど、画像のプルシークレットなど。

注記

認証されたユーザーとして画像を取得する場合、Docker Hubのプルレート制限。詳細については、「」を参照してください。コンテナインスタンスのプライベートレジストリの認証。

Amazon ECR と Amazon ECR パブリックを使用することで、Docker によって課される制限を回避できます。Amazon ECR からイメージをプルすると、ネットワークのプル時間を短縮し、トラフィックが VPC から離れたときのデータ転送の変更を減らすことができます。

重要

Fargate を使用する場合、プライベートイメージレジストリーへの認証はrepositoryCredentials。Amazon ECS コンテナエージェントの環境変数を設定することはできませんECS_ENGINE_AUTH_TYPEまたはECS_ENGINE_AUTH_DATAを変更するか、ecs.configファイルは、Fargate でホストされているタスク用です。詳細については、「」を参照してください。タスクのプライベートレジストリの認証。

Amazon EC2 コンテナインスタンスのロール

Amazon ECS コンテナエージェントは、Amazon ECS クラスター内の各 Amazon EC2 インスタンスで実行されるコンテナです。これは、Amazon ECS の外部でinitコマンドは、オペレーティングシステム上で使用できます。そのため、タスクロールを通じてアクセス許可を付与することはできません。代わりに、エージェントが実行される Amazon EC2 インスタンスに権限を割り当てる必要があります。例のアクションリストAmazonEC2ContainerServiceforEC2RoleポリシーをecsInstanceRole。これを行わないと、インスタンスはクラスターに参加できません。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "ec2:DescribeTags",
                "ecs:CreateCluster",
                "ecs:DeregisterContainerInstance",
                "ecs:DiscoverPollEndpoint",
                "ecs:Poll",
                "ecs:RegisterContainerInstance",
                "ecs:StartTelemetrySession",
                "ecs:UpdateContainerInstancesState",
                "ecs:Submit*",
                "ecr:GetAuthorizationToken",
                "ecr:BatchCheckLayerAvailability",
                "ecr:GetDownloadUrlForLayer",
                "ecr:BatchGetImage",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

このポリシーでは、ecrおよびlogsapi アクションを使用すると、インスタンスで実行されているコンテナが Amazon ECR からイメージを取得し、Amazon CloudWatch にログを書き込むことができます。-ecsアクションを使用すると、エージェントはインスタンスを登録および登録解除し、Amazon ECS コントロールプレーンと通信できます。このうち、ecs:CreateClusterアクションはオプションです。

サービスにリンクされたロール

Amazon ECS のサービスリンクロールを使用すると、代理で他のサービス API を呼び出すアクセス権限を Amazon ECS サービスに付与できます。Amazon ECS には、ネットワークインターフェイスの作成と削除、ターゲットグループへのターゲットの登録、登録解除を行う権限が必要です。また、スケーリングポリシーを作成および削除するのに必要なアクセス許可も必要です。これらのアクセス許可は、サービスにリンクされたロールを通じて付与されます。このロールは、サービスの初回使用時にユーザーに代わって作成されます。

注記

サービスにリンクされたロールを誤って削除した場合は、再作成することができます。手順については、以下を参照してください。サービスにリンクされたロールの作成。

Recommendations

タスク IAM ロールとポリシーを設定するときは、次の操作を実行することをお勧めします。

Amazon EC2 メタデータへのアクセスをブロックする

Amazon EC2 インスタンスでタスクを実行する場合は、Amazon EC2 メタデータへのアクセスをブロックして、コンテナがそれらのインスタンスに割り当てられたロールを継承しないようにすることを強くお勧めします。アプリケーションがAWSAPI アクションを使用する場合は、代わりにタスクに IAM ロールを使用します。

でタスクが実行されないようにするにはブリッジモードが Amazon EC2 メタデータにアクセスできないようにするには、次のコマンドを実行するか、インスタンスのユーザーデータを更新します。インスタンスのユーザーデータを更新する方法の詳細については、このAWSSupport 記事。タスク定義ブリッジモードの詳細については、タスク定義ネットワークモード。

sudo yum install -y iptables-services; sudo iptables --insert FORWARD 1 --in-interface docker+ --destination 192.0.2.0/32 --jump DROP

再起動後もこの変更が維持されるようにするには、Amazon マシンイメージ（AMI）に固有の次のコマンドを実行します。

  • Amazon Linux 2

    sudo iptables-save | sudo tee /etc/sysconfig/iptables && sudo systemctl enable --now iptables

  • Amazon Linux

    sudo service iptables save

使用するタスクの場合awsvpcネットワークモードでは、環境変数ECS_AWSVPC_BLOCK_IMDS～true()/etc/ecs/ecs.configファイルを開きます。

設定する必要がありますECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST変数をfalse内で実行されているコンテナーを防ぐために、ecs-agent 設定ファイルにhostネットワークが Amazon EC2 メタデータにアクセスしないようにします。

を使用するawsvpcネットワークモード

ネットワークを使用するawsvpcネットワークモードを使用して、異なるタスク間、またはタスクと Amazon VPC 内で実行される他のサービス間のトラフィックのフローを制限できます。これにより、セキュリティレイヤーが追加されます。-awsvpcネットワークモードは、Amazon EC2 で実行されるタスクのタスクレベルのネットワーク分離を提供します。これは、上のデフォルトモードです。AWS Fargateです。これは、セキュリティグループをタスクに割り当てるために使用できる唯一のネットワークモードです。

IAM アクセスアドバイザーを使用してロールを絞り込む

使用されなかったアクションやしばらく使用されなかったアクションは削除することをお勧めします。これにより、不要なアクセスが防止されます。これを行うには、IAM Access Advisor によって生成された結果を確認し、使用されなかったアクションや最近使用されなかったアクションを削除します。これは、以下の手順に従って行います。

次のコマンドを実行して、参照先ポリシーの最終アクセス情報を示すレポートを生成します。

aws iam generate-service-last-accessed-details --arn arn:aws:iam::123456789012:policy/ExamplePolicy1

の使用JobId出力に含まれていて、次のコマンドを実行します。これを行うと、レポートの結果を表示できます。

aws iam get-service-last-accessed-details --job-id 98a765b4-3cde-2101-2345-example678f9

詳細については、「」を参照してください。IAM アクセスアドバイザー。

監視AWS CloudTrail不審なアクティビティ

モニタリングできますAWS CloudTrail不審な活動のために。ほとんどの OSAWSAPI コールは、AWS CloudTrailをイベントとして。これらはで分析されますAWS CloudTrailインサイトにアクセスすると、writeAPI コール。これには、コール量のスパイクが含まれる場合があります。これらのアラートには、異常なアクティビティが発生した時刻や、API に貢献した最上位のアイデンティティ ARN などの情報が含まれます。

IAM ロールを持つタスクによって実行されるアクションは、AWS CloudTrailを見て、イベントのuserIdentityプロパティ. 次の例では、arnには、引き受けたロールの名前が含まれ、s3-write-go-bucket-roleにタスクの名前、7e9894e088ad416eb5cab92afExample。

"userIdentity": {
    "type": "AssumedRole",
    "principalId": "AROA36C6WWEJ2YEXAMPLE:7e9894e088ad416eb5cab92afExample",
    "arn": "arn:aws:sts::123456789012:assumed-role/s3-write-go-bucket-role/7e9894e088ad416eb5cab92afExample",
    ...
}
注記

ロールを引き受けるタスクが Amazon EC2 コンテナインスタンスで実行されると、Amazon ECS コンテナエージェントによってリクエストが記録され、/var/log/ecs/audit.log.YYYY-MM-DD-HHの形式で設定。詳細については、「」を参照してください。タスク IAM ロールログおよび証跡のインサイトイベントの記録。