IAMのService-Linked RolesがCloudFormationに対応したので、とてもナイスなリリースということを詳しく書いてみた。

CloudFormationがIAMの「Service-Linked Roles」に対応しました。何がうれしいのかその詳細を探ります。

#AWS CloudFormation

#AWS IAM

#AWS

市田善久

2018.08.11

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

まいど、大阪の市田です。先日、CloudFormationのドキュメントを眺めている時に、偶然ドキュメントの更新履歴から「IAMのService-Linked Roles作成がCloudFormationに対応した」というリリースを発見しました。

Release History - AWS CloudFormation

02-update-history

書式も非常にシンプルです。(下記はYAMLの場合です)

Type: "AWS::IAM::ServiceLinkedRole"
Properties:
AWSServiceName: String
CustomSuffix: String
Description: String

詳細が記載されたドキュメントページは下記になります。

AWS::IAM::ServiceLinkedRole - AWS CloudFormation

今回新たにリリースされたのは「AWS::IAM::ServiceLinkedRole」というプロパティタイプですが、下記の通りドキュメント上だとまだメニューにリンクがありません。そのため、この機能の発見が遅くなってしまったのですが実際に利用できる状態になっていますので、ご紹介したいと思います。

03-nolink

（個別のドキュメントページは存在していたので、そのうちリンクにも表示されるようになると思います。）

Service-Linked Roleとは？

そもそも「Service-Linked Roleとは何ぞや」という話ですが、AWSの場合、あるサービスは別のサービスを利用していることがよくあります。例えば、EC2のAutoScalingではスケールアウト/インのトリガーにCloudWatchアラームを利用しています。

このように「そのサービスから他のAWSサービスを呼び出す」ためのIAMロールのことを「Service-Linked Role」、「サービスにリンクされたロール」と言います。先程の例だと「EC2のAutoScalingにリンクされたIAMロールは、CloudWatchアラームを操作できる権限を持っている」、と表現できます。

詳細については下記ドキュメントを参照してもらえればと思いますが、ザックリと理解いただけたかと思います。

サービスにリンクされたロールの使用 - AWS Identity and Access Management

使ってみた

全く大したことはないですが、せっかくなのでElastiCacheのロールで試してみます。実際には、AWS CLIやマネジメントコンソールでElastiCacheを作成する時に自動的にこのロールは作成されるので、ElastiCache用にCloudFormationで作成することは無いと思います。

Resources:
ElastiCacheServiceLinkedRole:
Type: "AWS::IAM::ServiceLinkedRole"
Properties:
AWSServiceName: elasticache.amazonaws.com
Description: "This is a test."

問題なく作成できました。

04-cfn

IAMのコンソールでも確認できました。

05-iam-ec

このように「Service-Linked Roles」をCloudFormationで作成すること自体はとても簡単です。また、この「Service-Linked Roles」は普段あまり意識することが無いため「何が嬉しいの？」という疑問も出てくると思います。しかも、ElastiCacheの場合はCloudFormationを利用する時でも、上記のように明示的にAWS::IAM::ServiceLinkedRoleを使わなくてもAWS側で自動的に作成してくれます。

そうなると、ますますAWS::IAM::ServiceLinkedRoleが何のためにあるのか、ということが気になってきますよね。そこで本エントリでは、「今回のアップデートの何がうれしいのか」という点に以後、焦点を当ててみようと思います。

CloudFormation対応でうれしい点

さて、「Service-Linked Role」が何なのか分かって実際の使い方も見ましたが、あらためて今回のアップデートの何がうれしいのでしょうか？

結論から言えば、「Service-Linked Role」を別作業として作成しなくてもよくなり、CloudFormationだけで対応できる幅が広がった、ということです。

結論はこれだけなんですが少し寂しいのでもう少し深掘りして、どういう時に使うのかという点をアップデートリリース以前の課題を踏まえてご紹介したいと思います。

アップデートリリース前の課題

この「Service-Linked Role」は、多くの場合でAWSサービスを作成する時に自動で作成されます。なので、ユーザが明示的にこのロールを作成することは、ほぼありません。これはマネジメントコンソールやAWS CLI、CloudFormationなど、どの作成手段の場合でも「ほぼ同様」です。

「ほぼ同様」とはどういう意味かというと、一部のサービスでは特定の手段で作成するときに、明示的に「Service-Linked Role」を作成しないと自動で作成してくれない場合がある、ということです。

より具体的に言うと、「マネージメントコンソールやAWS CLI利用時は自動的に作成されるけど、CloudFormationでは自動的に作成されないケースがある。」という課題がありました。

課題解決するためのこれまでの方法

例として、「Amazon Elasticsearch Service」(以下Amazon ES)で話をしていきたいと思います。

詳細は別エントリで紹介しますが、マネジメントコンソールで「Amazon ES」をVPC上に作成する時は自動的に「Service-Linked Role」を作成してくれます。

01-amazones-role

しかし、「Amazon ES」を一度も作った事がない場合は「Amazon ES用のService-Linked Role」が存在しません。その状況で、AWS CLIやCloudFormationで「Amazon ES」を作成すると「Service-Linked Role」は自動で作成されず、下記のようなエラーが出てしまいます。

An error occurred (ValidationException) when calling the CreateElasticsearchDomain operation: Before you can proceed, you must enable a service-linked role to give Amazon ES permissions to access your VPC.

つまり、マネジメントコンソールを使わない場合は事前に「Service-Linked Role」を作成しておく必要があるというわけです。

明示的に「Service-Linked Role」を作成する場合は、AWS CLIやAPIを利用できます。AWS CLIならcreate-service-linked-roleコマンドで作成できるので、スクリプトに組み込んで実行するのも容易です。

コマンドの内容は下記の通りとても簡単なものです。（以下はAmazon Elasticsearch Serviceの場合です。念の為。）

$ aws iam create-service-linked-role --aws-service-name es.amazonaws.com`

CloudFormationを使う場合

問題はCloudFormationで全部作りたい場合です。これまではCloudFormationで作成できなかったので、別途AWS CLIなどを使って別作業として作成する必要がありました。職場ポリシーで自由にAWS CLIなどをPCにインストールできないとか、ITに詳しくない人が作業しなければいけないような場合だと、これではちょっと困りますよね。

しかし、強引に全部CloudFormationだけでやろうとすると、一例として下記のような構成のCloudFormationを事前に実行することになって、とても大げさな内容になってしまいます…