从什么是account(账户)user(用户)role(角色)说起
aws提供的云服务要通过订阅的方式租用并且计费。而aws账户就是所有订阅,计费,云服务的一个独立空间,在这个空间中的所有资源都可以由账户随意调配。
容易混淆的是用户和角色:
用户主要针对的是具体的人或者组织或者应用程序,有固定的认证方式。
而角色可以理解为是一系列权限的集合。相比之下角色被认为是一种短期的,灵活的认证。并且角色可以实现跨账户访问。
🌰栗子
把账号类比于一个公司,公司中有各种资源 ,公司是一个独立的空间 ,公司可以分配拥有的资源。
登录到公司人事部的每一个具体的 员工都是一个用户,有固定的认证方式(比如员工牌)。
角色就是岗位,具体的人分配到不同的岗位上就会扮演不同的角色,角色是一系列权限的集合,一个员工业绩好分配到了项目经理的位置上,就具有了项目经理的权限,过了两个月因为业绩太差被分配到端茶倒水的位置上,就失去了项目经理的权限,只保留了端茶送水的权限,所以同一个员工(工牌号9527),同一个人,因为在不同的岗位上扮演不同的角色,相对应的权限也会发生变化。
最后跨账户访问,也就是跨公司访问的情况:A公司的员工9527,哪怕是项目经理,也无法进入B公司去使用项目经理的权限。也就是说员工9527,他是属于A公司的员工(A账户的用户),无法执行B公司的权限(没有B账户的权限),也无权访问B公司的文件(无权访问账户B的资源)。
但是假设B公司创建了一个岗位(B账号创建了一个角色),这个岗位需要其他公司派来一个苦逼的外包程序员(允许A账号的用户扮演B账号的角色),允许使用B公司的电脑,键盘,鼠标(一部分权限),但是不能吃B公司的零食。
这时候A公司的员工9527,虽然仍然归属于A公司,却可以在B公司扮演角色,明明是A公司的员工,获得了在B公司使用一部分权限的能力。
员工9527在A公司扮演现场工程师,在B公司扮演外包程序员(就是在下了)
这就是assume role。
写成policy
由于是B公司开通的岗位,所以应该在B公司上面开放权限,A公司的员工来不来是A公司的事情。
{
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:: A公司 : 现场工程师 / 外包程序员 "
},
"Action": "sts:AssumeRole"
}
]
}