aws ec2的iam role深度解析
Aws ec2 iam role
访问aws的各种service api的时候,都要先进行身份认证，有下面几种情况。
1.通过aws console web界面访问
用户名,口令,MFA(可选)
2.aws cli
需要在~/.aws目录下的credentials文件里面配置
aws_access_key_id
aws_secret_access_key
3.develop sdk
环境变量，配置文件，~/.aws目录下的credentials文件中配置均可
aws_access_key_id
aws_secret_access_key
可以看出来，除了console以外,其它情况下,都需要提供credential。
上面提到的credential是通过iam user登陆到aws console界面后创建的。credential的权限同iam user的权限是一样的。设想一下，如果root用户的credential信息被人利用,那么他可以做任何事情。所以，aws建议
不要生成root用户的credential，也就是aws_access_key_id和aws_secret_access_key，而是
创建其他的iam user，通过iam user获取credential，然后再分给其它人，程序或者工具使用。
虽然是使用iam user的credential，但是如果被人盗用，同样会产生很严重的后果。所以，对于
运行在ec2上的application来说，如果把credential配置在ec2的某个地方(环境变量，配置文件),
仍然存在很大的安全隐患，而且，如果以后credential发生变更，也会增加维护的成本。
所以，基于以上安全和维护的原因，aws ec2为application提供了一种类似于托管的方式，application
需要访问web service api的时候，由sdk内部实现直接向ec2 instance获取动态的临时credential，然后再用取得的credential发起https认证请求。这样一来，application就不需要理会credential的事情了。当然，
前提是需要配置好ec2的IAM role。
IAM role的创建：
Signin aws console -〉My Security Credentials -〉 Roles -〉Create new role -〉Select(Amazon EC2 role type) -〉Attach Policy -〉Next Step -〉Input Role name -〉Create role
通过console创建完IAM role的时候，会自动创建一个同名的instance profile，然后ec2 instance配置
iam role的时候，实际选择的是这个instance profile。在Attach Policy的时候，需要根据application实际需要访问哪些aws的service和resource进行相应的选取。
Attach IAM role：
１〉可以在创建ec2 instance的时候，指定instance profile
２〉对于执行中的ec2 instance，也可以attach指定的instance profile
可以通过ec2 meta-data来查看security-credentials信息：
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/role_name
{
"Code" : "Success",
"LastUpdated" : "2012-04-26T16:39:16Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "xxxx",
"SecretAccessKey" : "yyyy",
"Token" : "token",
"Expiration" : "2017-05-17T15:09:54Z"
}
application 使用aws sdk的话,sdk内部会自动为我们做这件事情，然后利用credentials对https request
进行签名。其实，ec2内部是通过role name调用sts(AWS Security Token Service)来获取credentials信息的。这种动态获取的credentials是有生存周期的，过期自动失效，ec2 instance会在过期之前自动获取新的credentials，sdk不需要关注过期的问题，ec2 instance会把有效的credentials保存在meta-data中，sdk只需要从meta-data中获取即可。