web-dev-qa-db-fra.com

Terraform: que fait AssumeRole: Service: ec2?

Que fait exactement ce rôle AWS?

Les bits les plus pertinents semblent être: "Action": "sts:AssumeRole", et "Service": "ec2.amazonaws.com"

Le rôle complet est ici:

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
}

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

amazon-web-servicesterraform
22
Snowcrash

Pour comprendre la signification de cela, il est nécessaire de comprendre certains détails du fonctionnement des rôles IAM.

Un rôle IAM est similaire à un utilisateur dans sa structure, mais plutôt que d'être accessible par un ensemble fixe d'informations d'identification, il est plutôt utilisé par en assumant le rôle, ce qui signifie demander et obtenir des informations d'identification API temporaires qui permettent de prendre des mesures avec les privilèges accordés au rôle.

Le sts:AssumeRole action est le moyen par lequel ces informations d'identification temporaires sont obtenues. Pour l'utiliser, un utilisateur ou une application appelle cette API à l'aide de certaines informations d'identification déjà obtenues, telles que la clé d'accès fixe d'un utilisateur, et renvoie (si cela est autorisé) un nouvel ensemble d'informations d'identification pour jouer le rôle. Il s'agit du mécanisme par lequel les services AWS peuvent appeler d'autres services AWS en votre nom, par lequel les profils d'instance IAM fonctionnent dans EC2, et par lequel un utilisateur peut temporairement changer de niveau d'accès ou de comptes dans la console AWS.

La stratégie de rôle détermine quels principaux (utilisateurs, autres rôles, AWS services) sont autorisés à appeler sts:AssumeRole pour ce rôle. Dans cet exemple, le service EC2 lui-même est autorisé à accéder, ce qui signifie qu'EC2 est capable de prendre des mesures en votre nom en utilisant ce rôle.

Cette ressource de rôle seule n'est pas utile, car elle n'a aucune stratégie IAM associée et n'accorde donc aucun accès. Ainsi, un aws_iam_role la ressource sera toujours accompagnée d'au moins une autre ressource pour spécifier ses autorisations d'accès. Il y a plusieurs moyens de le faire:

  • Utilisation aws_iam_role_policy pour attacher une stratégie directement au rôle. Dans ce cas, la stratégie décrira un ensemble d'actions AWS que le rôle est autorisé à exécuter, et éventuellement d'autres contraintes.
  • Utilisation aws_iam_policy pour créer une stratégie autonome , puis utilisez aws_iam_policy_attachment pour associer cette stratégie à un ou plusieurs rôles, utilisateurs et groupes. Cette approche est utile si vous souhaitez associer une seule stratégie à plusieurs rôles et/ou utilisateurs.
  • Utilisez des mécanismes spécifiques au service pour attacher des stratégies au niveau du service. Il s'agit d'une manière différente d'aborder le problème, où plutôt que d'attacher la stratégie au rôle, elle est plutôt attachée à l'objet dont l'accès est contrôlé. Le mécanisme pour ce faire varie selon le service, mais par exemple l'attribut policy sur aws_s3_bucket définit des stratégies spécifiques au compartiment; L'élément Principal du document de politique peut être utilisé pour spécifier les principaux (par exemple, les rôles) qui peuvent effectuer certaines actions.

IAM est un système flexible qui prend en charge plusieurs approches différentes du contrôle d'accès. L'approche qui vous convient dépendra en grande partie de la façon dont votre organisation aborde les problèmes de sécurité et de contrôle d'accès: gestion des stratégies du point de vue du rôle, avec aws_iam_role_policy et aws_iam_policy_attachment, convient généralement aux organisations qui ont une équipe de sécurité centralisée qui supervise l'accès à travers un compte, tandis que les stratégies spécifiques au service délèguent les décisions de contrôle d'accès à la personne ou à l'équipe responsable de chaque objet distinct. Les deux approches peuvent être combinées, dans le cadre d'une stratégie de défense en profondeur , telle que l'utilisation de politiques au niveau des rôles et des utilisateurs pour les contrôles d'accès "frontaliers" ( contrôler l'accès depuis l'extérieur ) et les politiques de niveau de service pour les contrôles d'accès internes (contrôler les interactions entre les objets de votre compte).

Plus de détails sur les rôles peuvent être trouvés dans le guide AWS IAM Rôles IAM . Voir aussi ( Gestion des accès , qui couvre les concepts généraux du contrôle d'accès dans IAM.

24
Martin Atkins