はじめに

2022年1月より、自社開発企業にSREエンジニアとしてジョインいたしました。
初月はObservabilityの向上に関連したタスクをいくつか行っています。
そのなかで、AWSのAssumeRoleまわりで混乱したので備忘録として残しておきたいと思います。

AssumeRoleとは

簡単に言うと、STS（Security Token Service）に対して行われるAPIアクションのことです。
最初、名前にRoleとついているだけにIAMロールの種類かと思ってしまいました。ややこしい。。。
このAPIアクションが行われることにより、既存のIAMロールを引き受ける（Assume）ことができます。

IAM Roleの構成情報

IAM Roleを引き受けることができると書きましたが、そもそもIAM Roleを構成している情報は何でしょうか。
それは以下３つとなります。

・RoleName
・Path
・AssumeRolePolicyDocument

RoleNameはその名の通りロールの名前です。パスはロールを種類ごとにまとめたいときにディレクトリ管理できるものです。
んで、AssumeRolePolicyDocument。（最初はロール？ポリシー？ドキュメント？どれやねん。てなりました）

そもそもIAMRoleは、STSに対してAssumeRoleのアクションをする（sts:AssumeRole）ことにより使えるようになります。
これです。例えばEC2からS3へアクセスしたい場合は、EC2がsts:AssumeRoleしてS3にアクセスできるようになります。
sts:AssumeRoleは、stsに対してRoleARN（例：arn:aws:iam:123456789012:role/role-nameみたいな文字列）を渡して、
一時キーとなるCredentialsを返してもらいます。これにより、先ほどのRoleARNであるIAMロールに設定された権限が一時的に使えるようになるわけです。

ただ、このAssumeRoleがどんなユーザ/リソースからも行えてしまってはセキュリティ的に問題がありますよね。
そこで先ほどのAssumeRolePolicyDocumentにより、sts:AssumeRoleできるユーザ/リソースを指定します。

IAMロール（IAMユーザもグループも）は作成した後でIAMポリシーをアタッチすることができるので、
AssumeRoleされるIAMロールにポリシーをアタッチすることで、特定のリソースにアクセスすることができるようになります。

クロスアカウントアクセスの実現

最後に例として、AWSとDatadogとの連携について見てみたいと思います。
AWSリソースの各種ログをFirehoseを通してDatadogへストリーミングしたり、Datadog LogsからAWS S3へログアーカイブしたい場合（要はクロスアカウントアクセスです）、sts:AssumeRoleをすることによりAWS⇆Datadogでデータをやり取りできるようになります。

Datadog logsからS3へログアーカイブしたいときのようなDatadogからAWSへの通信が発生する場合は、自分のAWS側のAssumeRolePolicyDocument内でDatadogのアカウントIDを指定します。このAssumeRolePolicyDocumentをIAMロールにアタッチすることで、DatadogとAWS間でクロスアカウントアクセスすることができます。
そして、このロールに対してS3へWriteできるポリシーをアタッチして、それをDatadog側がsts:AssumeRoleすることでS3へのアクセスが可能になります。

最後に

AssumeRoleについて、やっと理解できました。（間違ってたら言ってください）
（違う問題でTerraformでどう記述するのかみたいなところも課題ではありますが、、、）
今後もAWS、Terraformまわりでログを残しておきたいなあと思ったら投稿したいと思います。

PS）Kubernetesやってるけど、コンポーネントが多すぎる。。。