Terraform:что делает AssumeRole: сервис: 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
}

From:https://www.terraform.io/docs/providers/aws/r/iam_role.html

9
amazon-web-services terraform

1 ответов

чтобы понять значение этого, необходимо понять некоторые детали того, как работают роли IAM.

роль IAM похожа на пользователей в своей структуре, но вместо того, чтобы получить доступ к фиксированному набору учетных данных, он вместо этого используется предполагая, что роль, что означает запрос и получение временных учетных данных API, которые позволяют выполнять действия с привилегиями, предоставленными роли.

на sts:AssumeRole действие - это средства, с помощью которых получены такие временные учетные данные. Чтобы использовать его, пользователь или приложение вызывает этот API, используя некоторые уже полученные учетные данные, такие как фиксированный ключ доступа пользователя, и возвращает (если разрешено) новый набор учетных данных для выполнения роли. Это механизм, с помощью которого сервисы AWS могут вызывать другие сервисы AWS от вашего имени, с помощью которого профили экземпляров IAM работают в EC2 и с помощью которого пользователь может временно переключать уровень доступа или учетные записи в AWS приставка.

на взять на себя роль политика определяет субъекты (пользователям, другим ролям, сервисам AWS) разрешено вызывать sts:AssumeRole для этой роли. В этом примере самой службе EC2 предоставляется доступ, что означает, что EC2 может выполнять действия от вашего имени, используя эту роль.

этот ресурс роли только не полезно, Так как он не имеет каких-либо политик IAM, связанных и, таким образом, не предоставляет никаких доступ. Таким образом,aws_iam_role ресурс всегда будет сопровождаться по крайней мере одним другим ресурсом, чтобы задать разрешения на доступ. Есть несколько способов сделать это:

  • использовать aws_iam_role_policy чтобы присоединить политику непосредственно к роли. В этом случае политика будет описывать набор действий AWS, которые разрешено выполнять роли, а также другие ограничения.
  • использовать aws_iam_policy создать автономной политики, а затем использовать aws_iam_policy_attachment чтобы связать эту политику с одной или несколькими ролями, пользователями и группами. Этот подход полезен, если требуется присоединить одну политику к нескольким ролям и / или пользователям.
  • используйте специальные механизмы для присоединения политик на уровне сервиса. Это другой способ подхода к проблеме, когда вместо присоединения политики к роли она присоединяется к объекту, доступ к которому контролируется. Механизм для этого варьируется в зависимости от службе, но, например,policy атрибут on aws_s3_bucket устанавливает политики, специфичные для ведра;Principal элемент в документе политики может использоваться для указания, какие участники (например, роли) могут выполнять определенные действия.

IAM-это гибкая система, которая поддерживает несколько различных подходов к контроля доступа. Какой подход подходит для вас, во многом будет зависеть от того, как ваша организация подходит к вопросам безопасности и контроля доступа: управление политиками из ролевая перспектива, с aws_iam_role_policy и aws_iam_policy_attachment, обычно подходит для организаций, имеющих централизованную группу безопасности, которая контролирует доступ по всей учетной записи, в то время как политики для конкретных служб делегируют решения управления доступом лицу или команде, ответственным за каждый отдельный объект. Оба подхода могут быть объединены в рамках защита в глубину стратегия, например, использование политик уровня роли и пользователя для" пограничного " контроля доступа (контроль доступа из за пределами) и политики уровня обслуживания для внутреннего контроля доступа (управление взаимодействиями между объектами в вашей учетной записи).

более подробную информацию о ролях можно найти в руководстве AWS IAM роли IAM. См. также Управление Доступом, который охватывает общие концепции контроля доступа в IAM.

9