AWS STS – 以正确的方式设计IAM用户密钥

文 | 沉默恶魔(禁止转载,转载请先经过作者同意)
微信号:chenmoemo
关注公众号:AWS爱好者

Hello大家好,欢迎来到《AWS解决方案架构师认证 Professional(SAP)中文视频培训课程》,我们前几个视频课程都在讨论AWS STS服务,今天将继续AWS STS服务的内容—使用STS服务,为用户分配临时凭证访问AWS资源。

我们开始今天的课程内容。

1、一个用户案例:哪个方案最佳?

我们先看一个用户案例,张三是一个开发人员,他要在他本地的电脑环境测试他的代码。代码需要访问AWS S3,所以需要AWS的access & secret key 。那么以下哪个方案是实现需求的最佳的解决方案?

这是一个普遍的案例,相信在大多数组织中都发生过,开发人员想要在本地的电脑上测试他的代码,这样的话就不能附加角色到EC2,然后在要求研发人员登陆EC2上去做测试。在这种情况下,有三种方案能够满足开发人员的测试需求:

第一个方案,提供给研发人员access & secret key,然后告诉他不要与其他人员共享凭证。相信很多组织都是这么做的,可以满足需求,但不安全,而且多年的工作经历和教训告诉我们,他是一定会和其他人分享凭证的。

第二个方案,提供给研发人员access & secret key,然后确保凭证每90天进行一次轮换,这种方式看似比第一种方式安全些,因为增加了凭证的轮换。但是同样,如果这个凭证被泄露,90天的轮换间隔是一个很长的时间间隔,在泄露后轮换时间前,同样会造成安全隐患;而缩短轮换时间同样不是一个很好的解决方案,尤其是您的组织有几十、几百个用户需要凭证时,会给您的工作带来很高的复杂度。所以整体这个方案也不太理想。

第三个方案是允许研发人员使用AWS STS服务生成临时凭证,使用临时凭证访问资源。这个是最佳的解决方案。如果您在您的组织是解决方案架构师或者负责安全工程师,当开发人员或者其他人员请求凭证访问AWS资源时,请您采用这个方案。

在上节课将EC2元数据的临时凭证拷贝到了我本地的mac电脑,在本地访问AWS资源,那不是一个很理想的方式,接下来看下满足这个用户案例最佳的实现方式,也就第三个方案的具体配置步骤。

2、AWS STS服务生成临时凭证,使用临时凭证访问S3的实现步骤:

第三个方案是允许开发人员使用AWS STS服务生成临时凭证,使用临时凭证访问S3。所以我们要配置:通过将允许访问S3的权限策略附加到角色,开发人员通过sts:Assumerole的方式获得该角色的临时访问凭证,然后使用此临时访问凭证访问AWS S3。


PPT的图是最终的执行流程,非常清晰,开发人员在本地执行AssumeRole,然后IAM角色返回临时凭证,然后用户使用这个临时凭证访问S3,这种方式是AWS推荐的最佳实践,而不是通过将持久性凭证分配给用户直接使用。

所以接下来我们需要做三件事:
第一步,在IAM中建立一个角色(角色名:stroll)
第二步,附加一个S3ReadOnly策略到IAM角色,让这个角色有只读访问S3的权限
第三步,允许IAM用户也就是开发人员使用的用户执行STS Assume Role 权限,获得临时凭证
最终开发人员使用临时凭证访问S3。

为了加深大家的理解,还是老惯例直接实操演示:

注意,本课时的内容以及实操演示,其中IAM角色,IAM用户,以及S3存储桶都在同一个AWS账号下,并未跨AWS账号,本课时的内容只是为了帮助大家更好的理解获取角色的临时凭证访问资源。

当然,您也可以自行应用在跨AWS账户的方案中,比如实现在A账户中的用户通过B账户的角色临时凭证,访问B账户中的存储桶。

3、实操演示-配置:

登陆AWS管理控制台,进入IAM-用户,我们目前已经创建了开发用户zhangsan,没有附加任何权限。

然后,切换到我本地mac的终端,我们后面假设这个就是开发人员zhangsan要调试代码的终端,需要访问S3存储桶。

先看一下aws的credentials文件内容,我已经将zhangsan的访问密钥配置在了credentials文件的default中,可以核对下,ID后4位UDVX,切换到控制台,安全证书,密钥id后四位是UDVX是一致的,已经在本地终端credentials文件配置了IAM用户zhangsan的安全凭证。

我们现在在本地mac终端执行aws s3 ls ,返回的信息是访问被拒绝,无法访问,因为现在zhangsan这个用户没有附加任何权限。

我们现在进行第一步和第二步,在IAM中建立一个角色,并为该角色附加一个S3ReadOnly策略

进入IAM-角色-创建角色,有四个受信任实体的类型选项,我们在之前的视频课程使用过受信任实体为AWS产品-EC2,而这个案例研发人员要在本地调试,显然这个选项无法满足我们这个案例的需求。我们这次要选择受信任实体的类型为“其他AWS账户”,然后输入我们演示的账户的账户ID,大家还记得怎么查吧?在支持-支持中心,然后我们将账户ID复制进去, 然后下一步,附加权限策略我们选择s3readonly,下一步, 角色名称我们叫做stroll,然后创建角色。

现在角色已经创建完成了, 点击新创建的角色stroll,可以看到目前该角色只有一个s3readonly的访问策略,在看一下信任关系,委托人principal的内容为,所有在这个账户ID下的用户,允许执行sts:AssumeRole动作。

我们对比下在之前的课程中的附加到EC2的角色的principal内容,指定的是EC2 service ,我们今天这里指定的是账户arn,这里的区别大家要留意。

好的,我们继续

后面进行第三步,允许用户zhangsan STS Assume Role 权限。

也就是要配置IAM用户zhangsan允许执行STS Assume Role 权限,然后zhangsan就可以承担我们之前创建的stroll角色,使用此角色临时访问凭证只读访问AWS S3

下面我们开始配置第三步。

进入到IAM-用户-zhangsan,为了能够让zhangsan执行STS Assume Role 权限,我们添加一个内联策略,服务选择STS,操作选择assumerole,然后资源这里,我们要选择特定,需要指定允许zhangsan承担的角色的ARN,添加我们之前创建的角色的ARN,下一步,然后策略名称我们就输入AssumeRole,然后完成创建策略。

其实这里有两个策略限制对应的,第一个策略是允许zhangsan这个用户承担我们创建的stroll角色的权限,就是上一步配置的。第二个是在我们前面演示的stroll角色的信任关系中,指定了能够承担stroll角色的可信任的实体内容为所有在这个指定的账号id的用户,包括zhangsan都允许担任该角色,大家还记得吧?
所以大家要记得这两个对应关系。

PPT中的三个步骤我们配置完了,接下来就是要在我本地使用zhangsan用户获取我们创建角色的临时凭证,然后使用临时凭证访问S3。

4、实操演示-验证:

我们开始,切换到我本地的mac电脑终端,使用aws cli ,运行aws sts assume-role命令,为zhangsan用户生成我们创建角色stroll的临时安全凭证。

为了节省时间我已经将命令准备好了,cli命令以及对应的参数说明都可以到AWS的cli命令参考页面查询:


aws sts assume-role --role-arn arn:aws:iam::256454142732:role/stroll --role-session-name stroll。

我们看下这个命令,aws sts assume-role,参数–role-arn后,需要指定要承担角色arn,所以我们指定了我们创建的stroll角色的arn;–role-session-name指定唯一会话名称,我们就指定stroll。

我们现在复制一下命令到我mac终端执行一下,看一下返回结果,命令成功将临时凭证返回,包括accesskey secretkey以及session token等等。

我们现在执行下aws s3 ls,返回access denied ,还是禁止访问。因为我们这个zhangsan的用户,目前拥有的唯一权限策略就是sts:assume role,他本身没有s3相关权限。zhangsan需要通过以上这个aws sts assume-role命令返回stroll角色的临时凭证,然后使用这个临时凭证才可以访问S3。stroll是有s3readonly策略的,大家还记得吧。

所以我们现在编辑下aws credentials文件,将命令返回的临时凭证信息放进去,我们新建一个zhangsansts字段,然后将凭证复制进去。保存退出
然后 执行aws s3 ls --profile zhangsansts

可以看到我们现在可以访问S3存储桶,我们用户案例的演示就完成了。

以上这种授权访问AWS资源的方式是AWS推荐的最佳实践。

在补充一点知识,切换到AWS的assume-role命令参考页面,看一下[—duration-seconds ]参数,可以通过此参数指定临时凭证的过期间隔,默认为1小时,超过间隔后凭证将会轮换。

以上就是我们今天的课程内容,我们今天演示了IAM用户通过sts:assume role的方式,获得角色的临时访问凭证,通过将访问资源的权限附加到角色,然后用户使用临时访问凭证访问AWS资源。这种方式是AWS推荐的最佳实践,将凭证安全维持到了一个很高的级别,而不是通过将持久性凭证分配给用户使用这种粗放的方式。

注意,本课时的内容以及实操演示,其中IAM角色,IAM用户,以及S3存储桶都在同一个AWS账号下,并未跨AWS账号,本课时的内容只是为了帮助大家更好的理解获取角色的临时凭证访问资源。

好的,希望通过今天的课程,能够让大家更熟悉AWS STS服务。

希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助,如您有任何疑问,请联系我们:

  • 如果您想获取本课程全部课时,请扫PPT的二维码加入。
  • AWS爱好者的网址是www.iloveaws.cn,认证视频课程,免费的认证考试仿真题以及认证课程文章,都可以在网站找得到
  • 可以通过扫码加入【AWS爱好者】微信公众号,查看原创的AWS知识点相关文章。
  • 加入【AWS爱好者】微信群,和其他同学一起备考,以及探讨交流AWS相关知识。

我们今天的视频课程就到这里,感谢大家的观看,我们下一课程再见。

2022年12月21日

1 responses on "AWS STS - 以正确的方式设计IAM用户密钥"

  1. 2020年8月14日 更新内容
    去掉了一些“跨账户”等容易产生歧义的内容

Leave a Message

Setup Menus in Admin Panel

error: Content is protected !!