本記事は MIXI DEVELOPERS Advent Calendar 2024 のシリーズ2 24日目の記事です。
サロンスタッフ予約サービス minimo のソフトウェアエンジニアをしている yhamano0312 です。
minimo ではこれまで AWS アカウントへのログインに IAM User を利用していましたが、最近 AWS IAM Identity Center に移行しました。本記事では移行した背景と移行内容について紹介します。
IAM User の課題
IAM User は AWS を触ったことがある人は全員利用した経験があるでしょう。マネジメントコンソールにログインしたり、アクセスキーを発行して手元から AWS の API を呼び出すために利用します。個人開発や小規模システムで AWS を利用する場合は IAM User で運用しても問題になることは少ないです。しかし、商用や大規模システムとなってくると以下のような問題が発生します。
複数 AWS アカウントでの IAM User 運用
プロダクトや環境毎に AWS アカウントを用意することがベストプラクティスとされています。IAM User は単一の AWS アカウントに紐づくため、複数の AWS アカウントを運用している場合はアカウント毎に IAM User を用意する必要があります。また、マネジメントコンソールを利用して複数の AWS アカウントを操作する場合は都度ログアウトとログインを行う必要があり手間だったりします。この問題については単一のアカウントのみに IAM User を作成して、他のアカウントにはスイッチロールして操作することで一定解決可能ですが、依然としてそれぞれの AWS アカウントに対応する IAM ロールの作成および管理が必要となります。
IAM User の棚卸し
IAM User の管理は入退社と連動して行うことが多いと思います。そのため、定期的な IAM User の棚卸しが必要となります。しかし、日々の開発業務に追われていると棚卸しを忘れてしまい、退職者が退職後も AWS アカウントを操作出来てしまっていた等のセキュリティインシデントに繋がります。
アクセスキーの漏洩に怯える日々
AWS アクセスキー 漏洩 でググると数多くのインシデント事例が出てきます。ただ、漏洩に怯えながらもアクセスキーを発行して手元から AWS の API を叩きたい時はあります。そのため、2要素認証を必須にする IAM Policy を付与したり、aws-vault を利用してセキュアにアクセスキーをローカルに保存したりもできますが、設定が個人努力な所があったり若干使いづらかったりと解決策としては微妙だったりします。
AWS としても IAM User の利用は非推奨としている
AWS のドキュメントにも IAM User の利用を非推奨とする旨が多く表記されているようです。
AWS IAM Identity Center とは
IAM User の代替として AWS が推奨しているサービスに AWS IAM Identity Center (以下、IdC)があります。IdC は AWS アカウントへのシングルサインオン(SSO)を提供するサービスです。IdC を導入することで以下のようなメリットが挙げられます。
- 複数 AWS アカウントへのログインがスムーズ
- IdP と連携させることでユーザ/グループ管理を IdP 側に任せられる
- AWS CLI v2 を利用した一時的な認証情報の取得が可能
IdC への移行
これらの理由から minimo においても IAM User から脱却し IdC に移行することにしました。以降にどのような手順で移行していったのかについて説明します。
IdC が有効となっている AWS Organizations へ AWS アカウントを移行
IdC は AWS Organizations と連携するサービスとなっており、IdC を利用する場合は IdC が有効化された AWS Organizations に基本的に所属している必要があります。[1]MIXI では歴史的背景から複数の AWS Organizations を所有しています。minimo で利用している AWS アカウントは元々 IdC が有効化されていない AWS Organizations に所属していたため、IdC が有効化されている AWS Organizations に移行する必要がありました。移行方法はドキュメントに記載されています。AWS アカウントの移行自体は AWS Organizations の管理者の方と一緒に作業を行なって数分で完了したのですが、移行前の事前準備がいくつかあるため紹介します。
移行対象 AWS アカウントに有効なクレジットカードを登録しておく必要がある
既に何かしらの AWS Organizations に所属している AWS アカウントを別の AWS Organizations に直接移行できず、移行前の AWS Organizations から外れた後に移行先の AWS Organizations に所属する必要があります。この際に AWS Organizations から外れるための条件として移行対象の AWS アカウント請求設定に有効なクレジットカードを登録している必要があります。しかし、AWS Organizations に所属してる場合 AWS Organizations の管理アカウントに設定されたクレジットカードに請求されるため AWS Organizations のメンバーアカウントに有効なクレジットカードが登録されていないことが多いですが、minimo で利用している AWS アカウントにおいても有効なクレジットカードが登録されていませんでした。そのため、社内の経理と調整して社用のクレジットカードを登録しました。
Cost Explorer 情報をバックアップする
移行元 AWS Organizations から抜けたタイミングでそれまでの Cost Explorer 情報が見れなくなります。minimo では週次で Cost Explorer を確認して予期しないコスト増加等を気づけるようにしており、移行直後もそれまでの Cost Explorer 情報を見る可能性がありました。そのため、 Cost Explorer の情報を CSV にエクスポートして BigQuery に取り込むことで確認できるようにしました。
なお、請求情報は移行したとしても過去のものは確認可能です。
Terraform による IdC 権限定義
IdC による権限定義(だれにどのような権限をどの AWS アカウントに対して付与するか)は IdC の管理アカウントで行う必要があります。この管理アカウントは AWS Organizations 内で1つしか作成できない制限があります。MIXI には開発本部という組織横断でエンジニアリングを支援する組織があるのですが、この IdC の管理アカウントも開発本部が管理しています。そして、IdC による権限定義を Terraform で管理するリポジトリが用意されており、このリポジトリに権限定義の PR を出してマージすることで設定が反映され権限が付与されます。
こちらの仕組みや運用については別記事で紹介しています。
minimo ではサービスの IaC に CDK を採用しており、今まで Terraform を採用していませんでした。しかし、既に開発本部側で CI/CD を整備してくれていること、IdC の権限定義のみであれば複雑なコード定義にはならないことから Terraform による IdC 権限定義の運用することにしました。
IAM User に付与されていた policy 内容を極力そのまま IdC の権限セットに移行
IdC に移行するにあたって今まで IAM User で運用できていたことは IdC でも利用可能にするために、極力 IAM User に付与されていた policy をそのまま IdC の権限セットに設定しました。移行のタイミングで policy 自体の整理も検討したのですが、まずは IdC に移行することを優先し IdC 移行後に policy は整理することとしました。ただし、元々 IAM User に強い権限が付与されていた一部のエンジニアには ReadOnly の権限セットも付与するようにしました。これにより普段は ReadOnly の権限セットを利用し、障害対応等が必要な時だけ強い権限セットを利用することで比較的安全に AWS アカウントを操作可能となりました。
移行するにあたってつまづいた点としては customer managed policy の移行です。IdC の権限セットにも customer managed policy を attach 可能なのですが、IdC の管理アカウント外で権限内容を管理することになり管理が煩雑になることから inline policy で表現することにしました。しかし、custom policy は複数の policy 定義を attach 可能ですが、inline policy は1つの policy 定義のみ attach 可能です。複数の policy 定義を Terraform で上手くまとめることができないかを探してみたらありました。data source aws_iam_policy_documentにて source_policy_documentsを使えば複数の policy 定義を1つの policy 定義にまとめることができます。
以下は例えば移行元の IAM User に２つの customer managed policy が付与されており、それを IdC 側で inline policy として1つの policy 定義で表現したい場合の具体例です。
data "aws_iam_policy_document" "source_1" {
statement {
effect = "Allow"
actions = [
"cloudfront:DescribeFunction",
"cloudfront:Get*",
"cloudfront:List*"
]
resources = ["*"]
}
}
data "aws_iam_policy_document" "source_2" {
statement {
effect = "Allow"
actions = [
"rds:Describe*",
"rds:ListTagsForResource"
]
resources = ["*"]
}
}
data "aws_iam_policy_document" "merge" {
source_policy_documents = [
data.aws_iam_policy_document.source_1.json,
data.aws_iam_policy_document.source_2.json,
]
}
例の policy であればわざわざ2つに分けて定義せずに最初から1つにまとめるでも良いですが、この policy 定義が複雑だったり複数の組み合わせになってくると分けて定義してまとめた方がメンテナンス性や可読性の観点では良いです。
移行アナウンス
IdC への移行目的、 IdC でのマネジメントコンソールログインや AWS CLI の利用方法等をドキュメントにまとめてメンバーに公開しました。AWS アカウントへのログインはエンジニアだけでなく、デザイナー等の非エンジニアも行うため、なるべく AWS について詳しくない人も分かりやすい内容を心がけました。
移行期間を1ヶ月程設けて、その期間は IAM User と IdC 両方でログインできるようにしました。この期間で IAM User で行なっていた開発や運用が IdC でも可能なのかを確認してもらっています。
IAM User に紐づくアクセスキーの無効化
IdC に移行完了後は既存の IAM User を削除する予定ですが、万が一 IAM User に紐づいたアクセスキーが CI/CD や AWS リソース内で使われていた場合は業務に影響が出てしまいます。そのため、いきなり削除は行わずにアクセスキーの無効化を行いました。これにより何かしら影響が出たら対象のアクセスキーを有効化するのみで対応可能です。
2024/12/23 時点ではまだ移行期間中のため IAM User の削除は行なっていませんが、 IdC に移行したことによる問題点も今のところ無いため、近々 IAM User の削除する予定です。
まとめ
minimo で利用している AWS アカウントへのログインを IAM User から IdC に移行しました。IdC に移行し始めて数週間経ちますが、特に問題はなく IAM User よりも管理のしやすさや操作感が良くなりました。
IdC への移行で人に紐づく IAM User は削除可能なのですが、マシンユーザー用の IAM User は依然として残ります。こちらは IAM Role への移行を検討し IAM User の撲滅を目指して今後対応していきます。また、付与している policy 内容の整理も今後行なっていく予定です。
本記事が IdC の移行を検討している方の参考になれば幸いです。
最後に
MIXI では一緒に働く仲間を募集中です！詳細は採用ページをご覧ください。
-
IdC が有効化された AWS Organizations に所属していない AWS アカウントへ IdC でログインすることは可能ですが、考慮事項等が増えるため今回は採用しませんでした。 ↩︎
Discussion