En quoi consiste exactement "Assumer" un rôle dans AWS?
Question
Que signifie exactement "assumer" un rôle dans AWS et où la définition définitive est-elle fournie?
Contexte
Assumer un rôle est fréquemment utilisé et essayer de comprendre la définition et ce qu'elle signifie réellement.
Je suppose qu'un principal (utilisateur IAM, application s'exécutant dans une instance EC2, etc. qui appelle une action pour accéder aux ressources AWS) doit invoquer une action pour accéder à une ressource AWS:
AWS (API? Ou un runtime d'autorisation dans AWS?) Identifie les rôles auxquels le principal peut être accordé.
par exemple. si un utilisateur EC2 est spécifié pour exécuter l'appel d'API de rôle assumé et exécuter une application qui accède à des ressources AWS dans une instance EC2 à laquelle le profil IAM est attaché, alors:- Tous les rôles IAM du profil IAM EC2
- Rôles et stratégies IAM demandés dans l'appel de rôle assumé
- Rôles IAM accordés à l'utilisateur EC2
AWS trouve un rôle parmi les rôles qui ont la stratégie (action, ressource) qui permet au principe d'effectuer l'action sur la ressource.
- AWS bascule le rôle du principe sur le rôle identifié.
Lorsque l'étape 3 a eu lieu, il est dit "le principal a assumé le rôle". Est-ce correct?
Recherche
Avant qu'un utilisateur, une application ou un service IAM puisse utiliser un rôle que vous avez créé, vous devez accorder des autorisations pour basculer sur le rôle. Vous pouvez utiliser n'importe quelle stratégie attachée à l'un des groupes d'utilisateurs IAM ou à l'utilisateur lui-même pour accorder les autorisations nécessaires.
Assumer un rôle signifie demander à Security Token Service (STS) de vous fournir un ensemble d'informations d'identification temporaires - informations d'identification de rôle - qui sont spécifiques au rôle que vous souhaitez assumer. (Plus précisément, une nouvelle "session" avec ce rôle.)
Vous pouvez éventuellement inclure une stratégie avec cette demande, ce qui servira à limiter les autorisations des informations d'identification temporaires à un sous-ensemble de ce que les stratégies du rôle auraient autorisées.
Vous utilisez ensuite ces informations d'identification pour effectuer d'autres demandes. Ces informations d'identification ressemblent aux informations d'identification utilisateur IAM avec un identifiant de clé d'accès et un secret, mais la clé d'accès commence par ASIA au lieu de AKIA et il existe un troisième élément, appelé jeton de sécurité, qui doit être inclus dans les demandes signées avec les informations d'identification temporaires.
Lorsque vous effectuez des demandes avec ces informations d'identification temporaires, vous disposez des autorisations associées au rôle et non des vôtres (si vous en avez une) car vous avez pris une nouvelle identité. CloudTrail peut être utilisé pour retracer les informations d'identification du rôle jusqu'à l'utilisateur qui a assumé le rôle, mais sinon le service ne sait pas qui utilise les informations d'identification.
tl; dr: assumer un rôle signifie obtenir un ensemble d'informations d'identification temporaires qui sont associées au rôle et non à l'entité qui a assumé le rôle.
AWS (API? Ou un runtime d'autorisation dans AWS?) Identifie les rôles auxquels le principal peut être accordé.
Non. Vous spécifiez le rôle que vous souhaitez assumer.
Lorsque "vous" exécutez du code sur une instance EC2 et que l'instance a un rôle d'instance, l'infrastructure EC2 appelle en fait assume-role au nom de l'instance et vous pouvez récupérer les informations d'identification temporaires à partir du service métadonnées d'instance . Ces informations d'identification sont accessibles uniquement à partir de l'instance, mais elles ne sont pas stockées sur l'instance.
Lors de l'exécution d'une fonction Lambda, l'infrastructure Lambda contacte STS et place vos informations d'identification temporaires dans variables d'environnement . Encore une fois, ces informations d'identification sont accessibles à la fonction, sans être stockées à l'intérieur de la fonction.
Dans les deux cas, vous pouvez appeler assumer un rôle avec ces informations d'identification et assumer un rôle différent, mais cela ne devrait pas être nécessaire dans la plupart des environnements.
par exemple. si un utilisateur EC2 est spécifié pour exécuter l'appel d'API de rôle assumé et exécuter une application qui accède à des ressources AWS dans une instance EC2 à laquelle le profil IAM est attaché, alors:
AWS n'a aucune connaissance d'EC2 utilisateurs. Les rôles d'instance sont accessibles à tout ce qui s'exécute sur l'instance.
Tous les rôles IAM du profil IAM EC2
n profil d'instance ne peut inclure qu'un seul rôle .
Rôles et stratégies IAM demandés dans l'appel de rôle assumé
Vous demandez d'assumer exactement un rôle. Vous n'avez pas besoin de demander une stratégie - vous spécifiez une stratégie uniquement si vous souhaitez que les informations d'identification temporaires disposent des privilèges - moins que les informations d'identification de rôle ne le permettraient. Cela pourrait être quelque chose que vous feriez si vous aviez besoin que le code s'exécute dans un endroit non fiable - tel que du code dans un navigateur ou une application - pour pouvoir signer des demandes avec des informations d'identification.
AWS trouve un rôle parmi les rôles qui ont la stratégie (action, ressource) qui permet au principe d'effectuer l'action sur la ressource.
Non. Comme indiqué ci-dessus, vous demandez un rôle spécifique lorsque vous appelez assume-role.
AWS bascule le rôle du principe sur le rôle identifié.
Non. Vous faites le changement en utilisant les informations d'identification temporaires fournies.
J'ai créé le diagramme suivant pour moi-même afin de comprendre ce qu'est exactement assumer un rôle dans AWS. J'espère que vous le trouverez également utile.
Dans le schéma, je l'ai mis en 3 étapes:
- Préparer les rôles (ExecutionRole et AssumedRole)
- Créer une fonction Lambda sur le compte A (dans votre cas, c'est EC2)
- Exécutez la LambdaFunction.
Lorsque l'étape 3 a eu lieu, il est dit: "le principal a assumé le rôle". Est-ce correct?
Les étapes que vous avez mentionnées pour assumer un rôle sont correct.
Ici, le point important est la configuration de relation de confiance du rôle IAM où vous accordez à chaque utilisateur, application ou service IAM le rôle. C'est là que vous accordez l'autorisation d'assumer le rôle particulier.
Ceci est important à bien des égards, où il contrôle qui peut assumer le rôle et il est important de fournir non seulement le moindre accès au rôle, mais également d'accorder le moins d'entités qui peuvent assumer le rôle.