Autorisations pour AssumeRole, AssumeRoleWithSAML et AssumeRoleWithWebIdentity

La politique d'autorisations du rôle endossé actuellement déterminé les autorisations octroyées aux informations d'identification de sécurité temporaires renvoyées par AssumeRole, AssumeRoleWithSAML et AssumeRoleWithWebIdentity. Vous définissez ces autorisations lors de la définition ou de la mise à jour du rôle.

Le cas échéant, vous pouvez transmettre des politiques de session en ligne ou gérées en tant que paramètre des opérations d'API AssumeRole, AssumeRoleWithSAML ou AssumeRoleWithWebIdentity. Les politiques de session limitent les autorisations pour la session d'informations d'identification temporaires du rôle. Les autorisations de la session obtenues sont une combinaison des politiques basées sur l'identité du rôle et des politiques de session. Vous pouvez utiliser les informations d'identification temporaires du rôle dans les appels d'API AWS suivants pour accéder aux ressources du compte qui possède le rôle. Vous ne pouvez pas utiliser les politiques de session pour accorder plus d'autorisations que celles autorisées par la politique basée sur l'identité du rôle endossé actuellement. Pour en savoir plus sur la façon dont AWS détermine les autorisations effectives d'un rôle, consultez Logique d'évaluation de politiques.

Les politiques attachées aux informations d'identification ayant effectué l'appel d'origine à AssumeRole ne sont pas évaluées par AWS lors de la prise de décision d'autorisation ou de refus. L'utilisateur renonce temporairement à ses autorisations d'origine en faveur de celles affectées au rôle endossé. Dans le cas des opérations d'API AssumeRoleWithSAML et AssumeRoleWithWebIdentity, il n'existe aucune stratégie à évaluer, car l'appelant de l'API n'est pas une identité AWS.

Exemple : Octroi d'autorisations à l'aide d'AssumeRole

Vous pouvez utiliser l'opération d'API AssumeRole avec différents types de politiques. Voici quelques exemples.

Politique d'autorisations de rôle

Dans cet exemple, vous appelez l'opération d'API AssumeRole sans spécifier la politique de session dans le paramètre Policy facultatif. Les autorisations affectées aux informations d'identification temporaires sont déterminées par la politique d'autorisations du rôle endossé. L'exemple de politique d'autorisations suivant accorde au rôle l'autorisation de répertorier tous les objets contenus dans un compartiment S3 nommé productionapp. Il permet également au rôle d'obtenir, de placer et de supprimer des objets dans ce compartiment.

Exemple de politique d'autorisations de rôle

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}

Politique de session transmise en tant que paramètre

Imaginons que vous souhaitiez autoriser un utilisateur à endosser le même rôle que dans l'exemple suivant. Mais, dans ce cas, vous voulez que la session de rôle ait uniquement l'autorisation d'obtenir et de placer des objets dans le compartiment productionapp S3. Vous ne souhaitez pas l'autoriser à supprimer des objets. Pour cela, vous pouvez créer un rôle et spécifier les autorisations souhaitées dans la politique d'autorisations du rôle. Vous pouvez également appeler l'API AssumeRole et inclure des politiques de session dans le paramètre Policy facultatif dans le cadre de l'opération d'API. Les autorisations de la session obtenues sont une combinaison des politiques basées sur l'identité du rôle et des politiques de session. Les politiques de session ne peuvent pas être utilisées pour accorder plus d'autorisations que celles autorisées par la politique basée sur l'identité du rôle endossé actuellement. Pour de plus amples informations sur les autorisations de session de rôle, veuillez consulter Politiques de session.

Une fois que vous avez récupéré les informations d'identification temporaires de la nouvelle session, vous pouvez les transmettre à l'utilisateur auquel vous voulez donner ces autorisations.

Par exemple, imaginons que la politique suivante soit transmise en tant que paramètre de l'appel d'API. La personne qui utilise la session dispose d'autorisations pour effectuer uniquement les actions suivantes :

• Répertorier tous les objets du compartiment productionapp.

• Obtenir et placer des objets dans le compartiment productionapp.

Dans la session suivante, l'autorisation s3:DeleteObject est exclue du filtre et la session endossée n'obtient pas l'autorisation s3:DeleteObject. La politique définit les autorisations maximales pour la session de rôle afin qu'elle remplace les politiques d'autorisations existantes sur le rôle.

Exemple de politique de session transmise avec l'appel d'API AssumeRole

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::productionapp"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::productionapp/*"
    }
  ]
}

Politique basée sur une ressource

Certaines ressources AWS prennent en charge les politiques basées sur des ressources, et ces dernières fournissent un autre moyen de définir des autorisations affectant les informations d'identification de sécurité temporaires. Seules quelques ressources, comme les compartiments Amazon S3, les rubriques Amazon SNS et les files d'attente Amazon SQS, prennent en charge les politiques basées sur des ressources. L'exemple suivant développe les exemples précédents, à l'aide d'un compartiment S3 nommé productionapp. La politique suivante est attachée au compartiment.

Lorsque vous attachez la politique basée sur les ressources suivante au compartiment productionapp, tous les utilisateurs se voient refuser l'autorisation de supprimer des objets du compartiment. (Voir l'élément Principal dans la politique.) Cela inclut tous les utilisateurs du rôle endossé, même si la politique d'autorisations du rôle accorde l'autorisation DeleteObject. Une instruction Deny explicite a toujours priorité sur une instruction Allow.

Exemple de politique de compartiment

{
  "Version": "2012-10-17",
  "Statement": {
    "Principal": {"AWS": "*"},
    "Effect": "Deny",
    "Action": "s3:DeleteObject",
    "Resource": "arn:aws:s3:::productionapp/*"
  }
}

Pour plus d'informations sur la manière dont AWS combine et évalue plusieurs types de politiques, consultez Logique d'évaluation de politiques.