AWS EC2有一个元数据区，里面可以保存一些数据。AWS有一个创新是在元数据区保存角色信息，角色的Principal指定为ec2服务。EC2基础设施会保证获取并更新STS token，部署在EC2上的服务可以直接从元数据区获取STS token，不再需要写获取和刷新STS token的逻辑。
通过curl保留169.254.169.254这个保留地址，可以读取实例元数据。更详细的操作请参考文档：Instance Metadata and User Data。
[root@ip-172-31-3-86 current]# curl http://169.254.169.254/latest/meta-data/ami-id
ami-d496a0b4
[root@ip-172-31-3-86 current]# curl http://169.254.169.254/latest/meta-data/local-hostname
ip-172-31-3-86.us-west-1.compute.internal
下面以一个Elastic Beanstalk的例子：eb-java-scorekeep来展示一下如何使用EC2上的角色。这是一个很简单的游戏，但是串联了很多AWS服务，比如Elastic Beanstalk、Dynamo DB。不同的分支增加了更多服务的接入，如x-ray、CloudWatch等。
在Elastic Beanstalk上传zip包的时候，默认需要关联一个角色。为了获得数据库读写权限，需要进入IAM给这个角色增加AmazonDynamoDBFullAccess权限。详细信息请参考文档：管理 Elastic Beanstalk 服务角色。
翻看eb-java-scorekeep工程的代码，可以发现使用DynamoDB时，完全没有权限相关的代码，都是直接拿到client就用起来了。
/** AWS SDK credentials. */
private AmazonDynamoDB client = AmazonDynamoDBClientBuilder.standard()
.build();
private DynamoDBMapper mapper = new DynamoDBMapper(client);
private final SessionModel sessionModel = new SessionModel();
private final GameModel gameModel = new GameModel();
public void saveMove(Move move) throws SessionNotFoundException, GameNotFoundException {
// check session
String sessionId = move.getSession();
String gameId = move.getGame();
if (sessionModel.loadSession(sessionId) == null ) {
throw new SessionNotFoundException(sessionId);
}
if (gameModel.loadGame(gameId) == null ) {
throw new GameNotFoundException(gameId);
}
mapper.save(move);
}
AWS SDK获取credentials provider顺序如下所示，Instance profile credentials在最后面。
通过这个附加角色，curl可以获取到角色对应的STS token。更详细的操作请参考文档：IAM Roles for Amazon EC2。
AWS在控制台里面可以给EC2附加角色。一台EC2只能附加一个角色。一个角色可以附加的策略数量是有限的，这样的限制，会导致用户可能要写出非常复杂的policy。在控制台上感知不到instance profile的存在，AWS会自动为role创建同名的instance profile，并将role加入到profile中。如果是在命令行操作，那么就需要手动去做这些事情了。
授予ec2.amazonaws.com这个服务账号assumeRole权限。
在命令行下面操作也是非常方便的。
如果子账号想给EC2机器附加某个角色，则需要主账号给子账号的权限中增加passRole的配置，policy的resource指定这个角色。这样子账号登录之后，在角色输入框中会将子账号能够passRole的角色显示出来。详情请参考：Granting a User Permissions to Pass a Role to an AWS Service。
不过服务器端的安全性是比较高的，普通用户可能会在代码里面写死子账号的AK信息。能防外贼防不了内贼。AK写到客户端里面，是外贼和内贼都防不了，需求会更加迫切一点。给业务服务配置不同的角色增加安全性更加符合规范，需要给开发者普及这个理念。
参考资料。
- 目前阿里云已经支持这一模式，详细信息请参考：在ECS上“无AK”访问。控制台相关的功能还在开发中。
- ECS实例RAM角色实践，在https://apigateway.console.aliyun.com里面实践一把也不错。
- Using Instance Profiles
- Working with AWS Credentials
- New! Attach an AWS IAM Role to an Existing Amazon EC2 Instance by Using the AWS CLI
