关于用户、组、角色、策略与AWS服务关联关系的技术问询

核心逻辑 #

IAM（身份访问管理）的所有组件，本质都是为了精准控制谁能对哪些AWS服务做什么操作——策略是权限的规则手册，用户、组、角色是需要被授权的身份实体，AWS服务是被访问的目标对象。

各组件的具体关联 #

用户与组 #

• 用户是单个IAM身份，对应具体的人或者独立运行的应用程序；组是用户的集合，用来批量管理权限，避免给每个用户单独加策略的麻烦。
• 策略可以直接绑到用户身上，也可以绑到组——组里的所有用户会自动继承组的策略权限。
• 这俩都是长期身份，一般有固定的访问凭证（比如Access Key），适合长期稳定的访问场景。

策略与AWS服务的关系 #

• 策略是用JSON写的权限规则文档，里面明确规定了允许或拒绝访问哪些AWS服务的哪些操作（比如允许读取S3桶里的文件，禁止删除EC2实例）。
• 策略不能直接附加到AWS服务，服务本身是被访问的对象，权限控制是针对“访问服务的实体”，而不是服务自己。
• 策略和服务的绑定是间接的：通过在策略里指定服务的操作、资源，来限制实体对该服务的访问范围——比如一条S3策略，就是专门针对S3服务的特定桶和操作生效的。

角色的定位 #

• 角色是临时身份，没有固定的长期凭证，而是通过临时安全令牌获取权限，令牌有效期最长12小时，过期自动失效。
• 角色的核心作用是权限委托，解决跨身份、跨服务的访问需求：
  • 让IAM用户临时切换权限（比如平时用普通权限，需要操作敏感资源时切换到管理员角色）；
  • 让AWS服务之间互相调用（比如Lambda函数要读取S3里的数据，就给Lambda绑一个有S3访问权限的角色，Lambda运行时会自动“扮演”这个角色）；
  • 让外部身份（比如企业内部AD用户、其他云平台用户）访问AWS资源。
• 策略同样可以附加到角色，当某个实体“扮演”这个角色时，就拥有了角色上绑定的所有权限。

内容的提问来源于stack exchange，提问作者variable