こんにちは。 SRE の @suzuki-shunsuke です。 AWS SSO を導入してセキュリティと利便性を改善した話を紹介します。
背景
これまで弊プロダクトチームでは各開発者に AWS IAM User を作成し、 IAM User の ID/Password で AWS にサインインし、 IAM User の Access Key を使って AWS CLI などを実行したりしていました。
しかし、この運用にはセキュリティと利便性の観点で以下のような課題がありました。
- セキュリティ
- Access Key が流出するリスクがある
- 退職後も IAM User が残り続けてしまうリスクがある
- 利便性
そこで AWS SSO を導入し、プロダクトチーム全員が持っている Google アカウントでサインイン出来るようにすることでこれらの課題を解決しました。
導入の流れ
AWS Organizations の導入
弊プロダクトチームでは AWS Organizations も導入されていなかったので、まずは AWS Organizations を導入しました。 master Account 用に、普段使っている AWS Account とは別に新しく AWS Account を作成し、 AWS Control Tower を使って Landing Zone を起動しました。
弊プロダクトチームではプロダクトが動いている AWS Account (以下本番 Account) とは別に AWS の検証用の Account (以下 Sandbox Account) があります。 本番 Account の前にまずは Sandbox Account を Organization に招待・追加し、 AWS SSO などの検証を行いました。
SSO の設定
SSO の設定では以下のドキュメントを参考に Google Workspace と AWS を設定しました。
SSO でサインインするには AWS SSO で以下のような設定が必要です。
- SSO
- User, Group を作成
- User を Group に追加
- Permission Set を作成
- User (Group) を Account に Assign
SSO User の name は Google Workspace の User の email と同じでないといけません。
SSO User, Group は後述する ssosync で管理し、それ以外の Permission Set などは Terraform で管理するようにしました。
ssosync による Google Workspace と AWS SSO の同期
SSO User, Group は ssosync という AWS 公式のツールを使って Google Worksapce を同期するようにしました。
ssosync を実行するために Google Cloud Project (以下 GCP) の Service Account を作ったりする手順に関しては ssosync のドキュメントに書いてあります。
https://github.com/awslabs/ssosync#configuration
ただし、 v1.0.0-rc.9 では幾つか問題があったため、独自に fork して自分でビルドしたものを使うことにしました。 以下の PR がマージされてなかったので、 fork して取り込みました。
ssosync を Lambda で動かす
そして Lambda で定期実行するようにしました。 Lambda 以外(IAM User とか)は Terraform で管理し、 Lambda は lambroll でデプロイしています。
ssosync を Lambda で動かす場合の設定はコードを読まないとわかりにくかったのですが、 AWS Secrets Manager で次のような名前の Secret を作る必要があります。
ref. https://github.com/awslabs/ssosync/blob/v1.0.0-rc.9/internal/config/secrets.go#L22-L40
- SSOSyncGoogleAdminEmail
- SSOSyncSCIMAccessToken
- SSOSyncSCIMEndpointUrl
- SSOSyncGoogleCredentials
IAM User, User Group を元に SSO Permission Set を作成する
SSO への移行に際しては、基本的に権限は変わらないように心がけました。 これまでは IAM User Group に複数の IAM Policy を割り当て、かつ IAM User を複数の Group に所属させることで IAM User の権限を管理していました。 一人のユーザーが複数の IAM User を使い分けることはありませんでした。
SSO の場合サインイン時に Permission Set を選択することになりますが、ユーザーに Permission Set を色々使い分けさせることは混乱を招きかねないので、 IAM User に付与されている権限と同じ権限を持つ Permission Set を一つ用意してそれを使ってもらうようにしました。
Permission Set には Managed Policy をアタッチすることは出来ますが、 Custom Policy をアタッチすることは出来ません。 IAM では IAM Policy 及び Group によって権限を分割して管理出来ていましたが、 Permission Set では Custom Policy に関してはそれらを一つの Inline Policy で管理する必要があり、 IAM の権限をそのまま SSO に持ってくるのは結構大変でした。
これに関しては Terraform の AWS Provider の iam_policy_document の override_policy_documents によって複数の iam_policy_document をマージすることで対応しました。
k8s の aws-auth を更新する
AWS SSO で k8s にアクセスできるように、 ConfigMap aws-auth を更新しました。
mapRoles に AWS SSO によって作られる IAM Role を追加しました。
開発者へ案内し、段階的に移行する
開発者向けに SSO への移行に関するドキュメントを書き、全体に周知しつつ特定の Group から段階的に移行していきました。 SSO で大きな問題がないことを確認した上で IAM User を削除しました。
Terraform の AWS Provider などは AWS SSO に対応しているため特に問題がありませんが、 AWS SSO に対応していないツールを使っているケースがあり、それに関しては引き続き IAM User を使っています。これも将来的になんとかしたいとは思っています。
導入してみて
AWS SSO 導入後、ユーザーからも良い反応をもらっています。
やはり MFA が不要になることで便利になっているようです。
kubectl などを実行する際、これまで無期限だった Access Key に比べ、 12 時間ごとに aws sso login を実行しないといけない点は若干不便になっていますが、これは仕方ないと思います。
また、 SRE は developer と同じ Permission Set を利用することで developer の権限周りのトラブルの調査がしやすくなりました。
さいごに
AWS SSO によって、最初に背景で説明した課題が解決されセキュリティと利便性が改善されました。 既に説明したとおり、 SSO の導入に際し AWS Organizations も導入しました。 今後は AWS Account を適切に分割し、よりセキュリティと利便性を向上させることを検討しています。
