Différence entre le rôle IAM et l'utilisateur IAM dans AWS
Quelle est la différence entre un rôle IAM et un utilisateur IAM? Le IAM FAQ a une entrée l'expliquant, mais elle était vague et pas très claire:
Un utilisateur IAM a des informations d'identification permanentes à long terme et est utilisé pour interagir directement avec les services AWS. Un rôle IAM ne dispose d'aucune information d'identification et ne peut pas envoyer de demandes directes aux services AWS. Les rôles IAM sont destinés à être assumés par des entités autorisées, telles que des utilisateurs IAM, des applications ou un service AWS tel que EC2.
Je pense qu'un rôle IAM est utilisé pour les connexions fédérées (en utilisant un IdP avec des jetons SAML, par exemple) et qu'ils ne disposent pas de clés d'accès permanentes que vous pouvez télécharger comme les utilisateurs IAM classiques "informations d'identification").
Que veulent-ils dire quand ils disent qu'un rôle IAM ne peut pas envoyer de demandes directes aux services AWS? Je peux me connecter à AWS Console (la console Web) et créer des piles, etc., de sorte que cela ne peut pas être.
Que veulent-ils dire quand ils disent qu'un rôle IAM ne peut pas envoyer de demandes directes aux services AWS? Je peux me connecter à AWS Console (la console Web) et créer des piles, etc., de sorte que cela ne peut pas être.
Vous êtes un utilisateur IAM (avec quelques rôles IAM attachés).
Pensez aux rôles IAM en tant que capacités.
Vous donnez des possibilités à un utilisateur IAM (par exemple, "peut créer une fonction Lambda", "peut télécharger sur S3").
Note sur les utilisateurs fédérés:
De http://docs.aws.Amazon.com/IAM/latest/UserGuide/id.html :
Un rôle peut être attribué à un utilisateur fédéré qui se connecte à l'aide d'un fournisseur d'identité externe au lieu d'IAM. AWS utilise les détails transmis par le fournisseur d'identité pour déterminer le rôle mappé à l'utilisateur fédéré.
Ainsi, un utilisateur fédéré est similaire à un utilisateur IAM auquel vous pouvez attacher des rôles IAM. Sauf que vous avez un fournisseur d'identité externe.
Techniquement, vous n'utilisez PAS un rôle en tant qu'identité lorsque vous vous connectez à la console AWS. Vous utilisez votre compte d'utilisateur fédéré (avec ses propres rôles attachés) comme identité.
Pour comprendre la différence, passons aux connaissances de base de l'IAM
Contrôles IAM: Qui (authentification) peut faire quoi (autorisation) dans votre compte AWS . L'authentification (who) avec IAM est effectuée avec des utilisateurs/groupes et des rôles, tandis que l'autorisation (quoi) est effectuée par des stratégies.
Ici le terme
- Utilisateur - L'utilisateur final pense aux gens
Groupes - un ensemble d'utilisateurs sous un ensemble d'autorisations (stratégies)
Rôles - sont utilisés pour accorder des autorisations spécifiques à des acteurs spécifiques pour une durée déterminée. Ces acteurs peuvent être authentifiés par AWS ou par un système externe de confiance.
L'utilisateur et les rôles utilisent des stratégies pour l'autorisation. Gardez à l'esprit que l'utilisateur et le rôle ne peuvent rien faire jusqu'à ce que vous autorisiez certaines actions avec une stratégie.
Répondez à la question suivante, vous ferez la distinction entre utilisateur et rôle?
- Peut avoir un mot de passe? Oui-> utilisateur, non-> rôle
- Peut-on avoir une clé d'accès? Oui-> utilisateur, Non-> rôle
- Peut appartenir à un groupe? Oui-> utilisateur, non -> rôle
- Peut-il être associé à des ressources AWS (par exemple, des instances EC2)? Non-> utilisateur, oui-> rôle
AWS prend en charge 3 types de rôle pour différents scénarios.
- Rôles de service AWS (par exemple: EC2, Lambda, Redshift, ...)
- Accès entre comptes: attribution d'autorisations aux utilisateurs à partir d'un autre compte AWS, que vous contrôliez ces comptes ou non.
- Identity Provider Access: octroi d'autorisations aux utilisateurs authentifiés par un système externe approuvé. AWS prend en charge deux types de fédération d'identité: - Identité basée sur le Web, telle que Facebook, la gestion de la prise en charge de Goolge-IAM via OpenID Connect - Identité SAML 2.0 telle qu'Active Directory, LDAP.
Pour comprendre quel est le rôle, vous devez lire son cas d'utilisation, je ne veux pas réinventer la roue, veuillez donc lire les documents AWS suivants: https://aws.Amazon.com/blogs/security/ comment utiliser un utilisateur unique pour accéder facilement à tous vos comptes en utilisant the aws-cli/
https://docs.aws.Amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html
J'espère que ça aide.
Un utilisateur IAM est un compte qui peut être utilisé par une personne ou une application. Un utilisateur dispose d'informations d'identification pour se connecter et effectuer des actions avec les privilèges attribués à ce compte.
Un rôle IAM est quelque chose de virtuel qu'une ressource peut assumer. Par exemple, une instance EC2 peut assumer un rôle et exécuter une commande AWS avec les privilèges attribués. Il en va de même pour d'autres services tels que la passerelle API, Lambda, Kinesis, RDS, etc.
Que veulent-ils dire quand ils disent qu'un rôle IAM ne peut pas envoyer de demandes directes aux services AWS?
Le rôle lui-même ne peut exécuter aucune tâche, car il doit être assumé par quelqu'un ou quelque chose. Une personne peut également être une personne connectée via la fédération d'identité, puis assumer un rôle.
Les principaux acteurs de l'IAM sont utilisateurs , groupes , rôles et politiques . Et ce que vous devez comprendre à propos d’AWS et ne jamais oublier, c’est que
Tout dans AWS est une API
Et pour exécuter toute API ou l'une de ses méthodes, nous devons d'abord authentifier, puis autoriser cet utilisateur/groupe/rôle particulier.
Ex: un opérateur veut placer un objet dans un compartiment S3. Ce processus se produit via un ensemble d'appels d'API dans AWS. Fondamentalement, nous appelons l'API S3 et une méthode de celle-ci pour placer l'objet dans le compartiment particulier (par exemple, la méthode put_object_in_s3). Pour cela, nous pouvons vouloir fournir le nom du compartiment, de l'objet et, plus important encore, un ensemble d'informations d'identification (nom d'utilisateur avec mot de passe ou clé secrète, etc.) afin d'indiquer au moteur d'API AWS qui cet utilisateur/groupe/le rôle est.
La première chose que fait API Engine est la suivante: examinez les informations d'identification envoyées avec l'API. Ensuite, il valide ces informations d'identification (qu'elles soient correctes ou actives) indiquant que cette demande provient d'un utilisateur, d'un groupe ou d'un rôle réellement valide. Ensuite, ce que le moteur d’API fait (comme il sait maintenant qui a envoyé cette demande d’API) prend les documents de politique associés à l’opérateur particulier (utilisateur ou rôle) et les évalue en tant que vue unique. C'est-à-dire que nous vérifions si l'action appelée dans l'API est autorisée pour cet opérateur.
Utilisateur IAM - Dans le contexte d'IAM, un utilisateur est un opérateur nommé «permanent» (humain ou machine). Ce qui est important à noter, c’est que les informations d’identité (les informations d’identité peuvent être un mot de passe de nom d’utilisateur ou une clé d’accès ou une clé secrète) sont permanentes et restent chez cet utilisateur nommé. AWS sait donc quelles sont les méthodes d'authentification (méthode d'authentification par nom d'utilisateur, mot de passe ou méthode de clé secrète, etc.) de cet utilisateur (en tant que personne permanente et restant avec l'utilisateur).
Groupe IAM - Comme dans l'image ci-dessus, un groupe est un ensemble d'utilisateurs. Et notez qu'un utilisateur peut également appartenir à de nombreux groupes.
Rôles IAM - Les rôles ne sont pas des autorisations !!!. Un rôle est également une méthode d'authentification au même titre que les utilisateurs et les groupes IAM. En tant qu'utilisateur, un rôle est également un opérateur (il peut s'agir d'un humain, d'une machine). La différence est que les informations d'identification avec les rôles sont temporaires.
Documents de politique - Comme indiqué précédemment, les rôles ne sont pas des autorisations. Les autorisations dans AWS sont entièrement gérées par des objets appelés Policy Documents. Les documents de politique sont des documents JSON. Les documents de stratégie peuvent être directement attachés à des utilisateurs, des groupes ou des rôles. Lorsqu'un document de politique est attaché à l'un des opérateurs ci-dessus, seuls ceux-ci qui obtiennent des autorisations font des choses. Un document de politique répertorie des éléments tels que: une API spécifique ou un groupe générique d’API qui obtient une liste blanche avec quelles ressources, et des conditions pour ces exécutions d’API (comme autoriser uniquement si cet utilisateur, groupe ou rôle dans le réseau domestique ou autoriser à partir de n’importe quel emplacement , permettez seulement à certains moments de la journée et etc)
Enfin et surtout, l'authentification dans AWS est effectuée via (utilisateurs IAM, groupes Et rôles), tandis que l'autorisation est réalisée par les stratégies.
Utilisateur IAM - Un utilisateur/application accédant à AWS Resources IAM Roles - Ensemble d'autorisations/de stratégies pouvant s'appliquer à un utilisateur ou à une ressource.
Vous pouvez également appliquer des rôles à un utilisateur IAM et à une ressource AWS., Par exemple, Appliquer le rôle IAM à la fonction Lambda. La fonction peut uniquement avec ce rôle IAM.