赞
踩
在什么时候场景下会使用到临时凭证操作
1.跨账户访问:当需要从一个AWS账户访问另一个AWS账户中的资源时,可以使用临时凭证来实现安全的跨账户访问。这避免了需要在多个账户中创建和管理长期凭证,同时还能应用细粒度的权限控制。
2.最小权限原则:为了遵循最小权限原则,可以创建一个角色,该角色仅拥有完成特定任务所需的最少权限,并允许必要的用户或服务扮演该角色。这样,即使是拥有较高权限的用户或服务也仅在需要时才能访问敏感资源或执行特定操作
3.临时任务和自动化脚本:对于需要临时执行的任务或自动化脚本,使用临时凭证可以确保这些操作在有限的时间内执行,并且在完成后,相关权限自动过期,从而减少安全风险。
用户A的权限:用户A需要有权限执行sts:AssumeRole
操作,并且这个权限应该(明确)指向角色B的ARN。
角色B的信任策略:角色B的信任策略需要明确允许用户A(或用户A所属的账户/角色)扮演角色B。
执行AssumeRole
操作:用户A执行sts:AssumeRole
操作,请求扮演角色B。
使用临时凭证:成功执行后,用户A会获得角色B的临时凭证,包括AccessKeyId
、SecretAccessKey
和SessionToken
,用户A可以使用这些凭证以角色B的身份执行AWS操作
确保正确配置信任关系和权限是实现这一过程的关键
首先需要用于一个拥有sts:AssumeRole权限的角色并且附加到ec2上
角色策略示例
- {
- "Version": "2012-10-17",
- "Statement": [
- {
- "Sid": "Statement1",
- "Effect": "Allow",
- "Action": "sts:AssumeRole",
- "Resource": "*" # 或者特定角色的arn
- }
- ]
- }
以下我已经附加到ec2上并且没有任何其他权限,只有一个sts:AssumeRole权限
附加到EC2中使用AWS cli命令查看s3,查看有没有权限
报错无权访问
创建一个角色只给他s3的查看权限,并且信任现在这个账户
创建成功以后修改他的信任策略
复制我们现在角色arn替换Principal中的信息
保存修改
返回cli使用aws sts命令
aws sts assume-role --role-arn "arn:aws:iam::123456789012:role/RoleName" --role-session-name "SessionName"
--role-session-name :创建一个会话名称
123456789012替换为你的aws账户id
RoleName替换成你需要获取凭证的角色名
使用aksk和token测试
测试权限
成功访问
去除临时凭证
unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
总的来说,IAM用户需要有执行sts:AssumeRole
的权限,并且目标角色的信任策略需要允许该用户扮演该角色。通过这种方式,用户可以获得角色的临时凭证并以该角色的身份执行操作。这是一个强大的功能,可以用于实现跨账户访问和权限委托等高级用例。
一旦角色A成功扮演了角色B并获取了临时凭证,就可以使用这些凭证来以角色B的身份进行AWS资源操作。
这个流程强调了IAM角色的强大功能,以及AWS对安全性和权限管理的细致控制。它使得跨账户访问、权限最小化和权限的动态管理变得可能。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。