我的猜测是,用户路径的使用更适合大型组织或高级用户,他们通常依赖CloudFormation和/或AWS CLI来管理他们的AWS资源。
路径清晰->
https://stackoverflow.com/a/46325139/13126651
我怎么看
groups
v/s
path
.
-
可能有
permissions(more than one)
这适用于开发组和特定用户
-
我们不想要
specific users
然而,要使用开发组策略,开发组也需要一些适用于开发人员用户的权限。
-
我会创造一个
dev path
-
通过为路径中的用户创建使用特定服务的策略,可以授予他们访问权限。
-
通过这种方式,将特定用户添加到dev路径,允许在不将其添加到dev组的情况下授予权限。
-
如果将来需要删除dev权限,只需删除路径即可。
使用路径的示例策略
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"iam:GetContextKeysForPrincipalPolicy",
"iam:SimulatePrincipalPolicy"
],
"Effect": "Allow",
"Resource": "arn:aws:iam::*:user/Department/Development/*"
}
]
}
组:
IAM用户组是IAM用户的集合。用户组允许您为多个用户指定权限,这样可以更轻松地管理这些用户的权限。例如,您可以拥有一个名为Admins的用户组,并为该用户组提供管理员通常需要的权限类型。该用户组中的任何用户都自动拥有分配给该用户组的权限。如果新用户加入您的组织并需要管理员权限,您可以通过将该用户添加到该管理员组来分配适当的权限
路径:
可以使用单个路径,也可以将多个路径嵌套为文件夹结构。例如,可以使用嵌套路径/division\u abc/subdivision\u xyz/product\u 1234/engineering/来匹配公司的组织结构。然后,您可以创建一个策略,以允许该路径中的所有用户访问策略模拟器API。
关键区别
如果用户和用户组位于同一路径中,IAM不会自动将用户放入该用户组中。例如,您可以创建一个开发者用户组,并将路径指定为/division\u abc/subdivision\u xyz/product\u 1234/engineering/。如果您创建一个名为Bob的用户并向其添加相同的路径,这不会自动将Bob放入开发者用户组。IAM不会根据用户或用户组的路径强制用户或用户组之间的任何边界。
