web-dev-qa-db-ja.com

Terraform：AssumeRole：Service：ec2は何をしますか？

このAWSロールは正確には何をしますか？

最も関連するビットは次のようです："Action": "sts:AssumeRole",および"Service": "ec2.amazonaws.com"

完全な役割はここにあります：

resource "aws_iam_role" "test_role" {
  name = "test_role"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

差出人： https://www.terraform.io/docs/providers/aws/r/iam_role.html

amazon-web-servicesterraform
22
Snowcrash

これの意味を理解するには、IAMロールがどのように機能するかの詳細を理解する必要があります。

IAMロールは、その構造においてuserに似ていますが、資格情報の固定セットからアクセスされるのではなく、assuming役割。これは、役割に付与された特権でアクションを実行できるようにする一時的なAPI資格情報を要求して取得することを意味します。

sts:AssumeRoleアクション は、このような一時的な認証情報を取得する手段です。これを使用するには、ユーザーまたはアプリケーションが、ユーザーの固定アクセスキーなどのすでに取得した資格情報を使用してこのAPIを呼び出し、役割として機能する新しい資格情報のセットを（許可されている場合）返します。これは、AWSサービスがユーザーに代わって他のAWSサービスを呼び出すメカニズム、EC2でIAMインスタンスプロファイルが機能するメカニズム、およびユーザーがAWSコンソール内のアクセスレベルまたはアカウントを一時的に切り替えることができるメカニズムです。

想定されるロールポリシーは、どのプリンシパル（ユーザー、その他のロール、AWS）を決定しますサービス）は、このロールに対してsts:AssumeRoleを呼び出すことが許可されています。この例では、EC2サービス自体にアクセス権が付与されています。つまり、EC2はこのロールを使用してユーザーに代わってアクションを実行できます。

このロールリソースaloneは、IAMポリシーが関連付けられていないため、アクセスを許可しないため、役に立ちません。したがって、aws_iam_roleリソースには常に、少なくとも1つの他のリソースが付随して、そのアクセス許可を指定します。これにはいくつかの方法があります。

  • aws_iam_role_policy を使用して、ポリシーをロールに直接アタッチします。この場合、ポリシーには、ロールの実行が許可されている一連のAWSアクションと、オプションで他の制約が記述されます。
  • aws_iam_policy を使用してstandaloneポリシーを作成し、次に aws_iam_policy_attachment そのポリシーを1つ以上のロール、ユーザー、およびグループに関連付けます。このアプローチは、単一のポリシーを複数のロールやユーザーに関連付ける場合に便利です。
  • サービス固有のメカニズムを使用して、サービスレベルでポリシーをアタッチします。これは、問題にアプローチする別の方法です。ポリシーをロールに添付するのではなく、アクセスが制御されているオブジェクトに添付されます。これを行うメカニズムはサービスによって異なりますが、たとえば aws_s3_bucket のpolicy属性はバケット固有のポリシーを設定します。ポリシードキュメントのPrincipal要素を使用して、特定のアクションを実行できるプリンシパル（ロールなど）を指定できます。

IAMは、アクセス制御へのいくつかの異なるアプローチをサポートする柔軟なシステムです。どのアプローチが適切であるかは、組織がセキュリティとアクセス制御の懸念にどのようにアプローチするかに大きく依存します。aws_iam_role_policyとaws_iam_policy_attachmentを使用してロールの観点からポリシーを管理することは、通常、集中型のセキュリティを持つ組織に適していますアカウント全体のアクセスを監督するチーム。サービス固有のポリシーは、アクセス制御の決定を個別のオブジェクトごとに責任を持つ人またはチームに委任します。両方のアプローチは、多層防御戦略の一部として組み合わせることができます。たとえば、「境界」アクセス制御にロールレベルおよびユーザーレベルのポリシーを使用する（ outside）からのアクセスを制御し、内部アクセス制御（アカウント内のオブジェクト間の相互作用を制御）のサービスレベルポリシー。

ロールの詳細については、AWS IAMガイド IAM Roles を参照してください。 アクセス管理 も参照してください。IAM内のアクセス制御の一般的な概念について説明しています。

24
Martin Atkins