この記事は Retty Advent Calendar 2022 Part2 の16日目の記事です。昨日はたちばなさんの『アイドルヲタクが応援うちわで考えるユーザー体験設計』でした。
もちろん Part1 もあります。Part 1 では CLI バージョンマネージャーに関する記事を書いたのでぜひ見てください！
はじめに
インフラチームの幸田です。何も考えずに同じ週に Part1 と Part2 の参加登録をしてしまって急いで記事を執筆しています。
今回は最近ようやく一段落ついた IAM User を減らすための取り組みについて紹介します。といっても目次の通りで、あまり凝った内容ではありませんが見て頂けると嬉しいです。
背景
Retty では AWS をメインで利用しており、プロダクトのほぼ全てが AWS 上で稼働しています。
メインのサービスに関わるリソースは、サービス開始当初から存在する AWS アカウント(以下メインアカウント)に存在しており、社内で最も利用されています。
サービス開始当初から使われた続けているアカウントだけあって、用途不明なリソースがたくさん存在していましたが、最近ようやく「どこに使われているのか分からないリソース」は見なくなってきました。
少しずつお掃除が進んでいったメインアカウントですが、今回はその中でも IAM User を減らすための取り組みを紹介します。
なぜ IAM User を減らしたいのか
そもそもなぜ IAM User を減らしたいと思ったのかをお話したいと思います。
(IAM User そのものの解説はここでは行いません。詳しくはドキュメントを参照してください。)
期限のないアクセスキーの漏洩リスク
ご存知の通り IAM User はパスワードを利用したマネジメントコンソールなどへのログインに加えて、アクセスキーを利用してAWS CLI など SDK を通して AWS を利用することができます。
アクセスキーには、アクセスキー ID (例: AKIAIOSFODNN7EXAMPLE) とシークレットアクセスキー(例: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY)が存在しており、この2つの情報を組み合わせることで IAM User に付与されたポリシーを利用して各種 API を呼び出すことができます。
このアクセスキーですが、有効期限が存在せずに永続的に有効なものとなっています。公式ドキュメントでも定期的に更新することがベストプラクティスとして挙げられています。
基本的にはこのキーが漏洩してしまうと IAM User に付与されたポリシーを誰でも、どこからでも利用できてしまいます。
開発者向けに発行している IAM User のアクセスキーの取り扱いには十分に注意を払ってもらっていますが、うっかりアクセスキーをリポジトリにコミットしてしまったり*1、外部の SaaS に預けていたものが漏洩してしまうといったケースも考えられます。
定期的にキーを入れ替えたりなど取れる手段はありますが、そもそも IAM User を使わなくても良いのであればそれに越したことはないかと思います。
管理コストの増加
現在は減ってきましたが複数の AWS にアカウントそれぞれの IAM User を作成するような方式を取っていました。管理するアカウントが増加する度に IAM User の数が増え、管理する側も、利用する側にとっても大きな負荷となっていました。
用途不明な IAM User が出てきたり、退職者の削除が漏れてしまうなどセキュリティインシデントに繋がりかねないため手に負えなくなる前にどうにかしたいと考えていました。
IAM User を減らすための取り組み
ここからは実際に行った取り組みについて紹介します。
IAM Identity Center (AWS SSO) の利用
まずは社内の利用者向けに発行していた IAM User を減らすために、可能な限り AWS アカウントを自前の AWS Organization 配下に統合し、AWS IAM Identity Center (旧 AWS SSO) を利用することにしました。
IAM Identity Center を利用することでなぜ IAM User が減らせるのか、どのようにしてユーザ管理や認証認可が行われるかについては、AWS が公式で出している下記ブログが参考になるかと思います。
AWS Organization を利用して複数の AWS アカウントを管理し、IAM Identity Center を利用することで、マネジメントコンソールにログインするために利用していた IAM User を廃止することができました。*2
SaaS 向け IAM User を IAM Role への切り替え
続いてが各 SaaS 向けに発行していた IAM User を廃止し、IAM Role への切り替えを行いました。
様々な SaaS と AWS アカウントを連携させる際、認証の選択肢として IAM User の認証情報を用いた方式があると思います。大抵の SaaS に用意されている印象です。
IAM User を用いた認証でも問題なく利用できますが、IAM Role を利用した認証が選択肢としてある場合には積極的にそちらを利用するのが望ましいと思います。
理由は冒頭にも書いたように、預けたアクセスキーが何らかの形で漏洩してしまうリスクがあるためです。
Retty では様々な SaaS を利用していますが、IAM Role を利用した認証方式 (AssumeRole) を採用しているものをいくつか紹介します。
Treasure Data
S3 への接続に IAM Role を利用しています。今年に入ってから登場したようで、下記のブログで概要からセットアップまで紹介されています。
Datadog
モニタリングの SaaS である Datadog も IAM Role による認証に対応しています。
Datadog の場合には、GovCloud / China を除いてはそもそも IAM User を使うことができず、IAM Role による設定が必須となっています。
Fastly
画像のリサイズや CDN で活用している Fastly も IAM Role に対応しています。
ただし IAM Role が利用できるのは S3 へのロギングのみであり、Origin を S3 のプライベートバケットにしているようなケースでは IAM User の発行が必要になります。
CI 向け IAM User を IAM Role への切り替え
Retty では CI として CircleCI と GitHub Actions の2つを利用しています。過去の記事でも取り上げましたが、CI からの認証にも IAM Role を利用しています。
GitHub Actions
いち早く対応したのが GitHub Actions ではないでしょうか？2021年10月頃に OIDC を利用した認証のサポートが発表されました。
今までは IAM User を発行して GitHub Actions に認証情報を預ける必要がありましたが、このアップデートにより IAM Role を利用することができるようになりました。詳しい仕組みなどは公式ドキュメントを参照してください。
また IAM Role が利用できるだけでなく、ワークフローが実行されるブランチやアクションに対して制限をかけることも可能です。先月書いた記事でこの辺りにも触れているので興味のある方は見てください。
CircleCI
いつ対応されるのかな…！と心待ちにしていた CircleCI も2022年3月頃にリリースされました。こちらも GitHub Actions でサポートされたものと似たような内容になります。
#OIDC リリースされました！
— CircleCI Japan (@CircleCIJapan) 2022年3月26日
(OpenID Connect Tokens)
Twitterでも「1月にでるはずだったよね」という期待をずいぶん頂き、ご関心をひしひしと感じてしました。
- Changelog: https://t.co/oqM0zbE2OF
- Doc: https://t.co/fOYKoKfTNd
こちらも設定方法はドキュメントを参照してください。
余談ですが、このアップデートが発表されるかどうかくらいのタイミングでマイクロサービス基盤の刷新を行っていたのでタイミングよく乗り換える事ができました。下記記事で当時の取り組みを紹介しているのでこちらもぜひ。
まとめ
知っている人からすると基本的なことばかりでしたが、以上が AWS IAM User を減らすための取り組みでした。
また SaaS 側が対応していないと思っていたら対応されていたケースもあるので、この機会にお使いの SaaS の対応状況を確認されてみてはいかがでしょうか。
引き続き Retty Advent Calendar をよろしくお願いします！
Part2 の明日の担当は同じチームにいる山田さんの『開発生産性を120%にブーストするIntelliJ IDEAのプラグイン紹介』です。
*1:これを防ぐために git-secrets などを利用するのがオススメです
*2:しかし一部のアカウントはリセラーの AWS アカウントであるため既存の AWS Organization に統合できていません😭
