AWS EMR内置Ranger插件使用的IAM Role及其设计策略

AWS EMR提供三种内置的Ranger插件，分别是：S3(EMRFS)，Spark，Hive，如果要启用这些插件，需要创建三个特定的IAM Role，以便相关组件能获得适当的权限。对这三种Role的介绍可参考官方文档：https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-ranger-iam.html 本文主要是解释一下三种Role之间的关系。

在创建标准EMR集群时，如果你有留意的话，应该会注意到EMR会自动创建并分配给各个EC2节点一个默认的IAM Role，这个Role叫做：EMR_EC2_DefaultRole，如果你查看一下这个Role的policies就会发现，这个默认的Role拥有很大的权限，包括对S3和Glue Data Catalog的全局读写权限，对于不做细粒度权限控制的EMR集群来说，这样做是没有问题的。当然，你可以以该Role为模板创建新的Role，删减或添加一些policies，例如限制EMR仅可以使用部分的S3桶。

如果打算启用EMR内置的Ranger插件，就会如前面文档所述，将要涉及到三个Role，看上去一下子变得复杂起来，但如果搞清楚了三个Role之间的关系，理解起来也很简单。我们先把三个Role列出来：

我们先把最重要的结论给出来，然后再做梳理。EMR_EC2_RangerRole对应标准EMR集群使用的EMR_EC2_DefaultRole，是在建EMR集群时通过“EC2 instance profile”这一选项选择的。但是与后者不同的是，EMR_EC2_RangerRole实际上是一个被“架空”的Role，它除了拥有获取SecretManager上指定证书的权限（该权限用户EMR所有节点获取TLS证书以便实现Ranger插件与Ranger Admin之间的TLS通信）外，就没有任何其他权限了；同时它允许另外两个Role带代入，则更加实际的权限分配其实是由另外两个Role定义的。在创建一个EMR Security Configuration时，在“IAM role for Apache Ranger”一项上，我们选取EMR_RANGER_PluginRole，EMR会将这个Role赋给Hive、Record Server（for Spark）使用，该Role通常会分配较大权限（例如S3桶全开），以保证这些服务拥有“充足”的IAM权限访问S3等资源，具体到用户级别的细粒度权限控制会由Ranger负责；而对于那些非Ranger插件服务，就可以最大程度上削减权限，以防止这些服务在IAM层级上获得不应有的权限。

上图展示了三个Role在控制台上的出现的位置以及相互之间的关系。如果用一句话总结EMR内置Ranger插件的IAM Role设计策略那就是：EMR将原来简单分配给EC2节点的EMR_EC2_DefaultRole 替换成了一个较为笼统的EMR_EC2_RangerRole，仅支持必须要的secret读取权限，然后再配置两个定向使用的Role，一个给需要运行Ranger插件的组件/服务使用，这个Role是EMR_RANGER_PluginRole，另一个给非使用Ranger插件的组件/服务使用，这个Role是EMR_RANGER_OtherRole