Autorisations pour AssumeRole, AssumeRoleWith SAML 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 lors des appels d' AWS API suivants pour accéder aux ressources du compte propriétaire du 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 stratégies.

Les politiques associées aux informations d'identification à l'origine de l'appel ne AssumeRole sont pas évaluées AWS lors de la prise de la décision d' « autoriser » ou de « refuser » l'autorisation. L'utilisateur renonce temporairement à ses autorisations d'origine en faveur de celles affectées au rôle endossé. Dans le cas des opérations AssumeRoleWithSAML et de l'AssumeRoleWithWebIdentityAPI, il n'y a aucune politique à évaluer car l'appelant de l'API n'est pas une AWS identité.

Exemple : attribution d'autorisations à l'aide de 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.

{
  "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 :

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.

{
  "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 AWS ressources prennent en charge les politiques basées sur les ressources, et ces politiques fournissent un autre mécanisme pour définir les autorisations qui affectent 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.

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

Pour plus d'informations sur la façon dont plusieurs types de politiques sont combinés et évalués par AWS, voirLogique d’évaluation de stratégies.