はじめに
こんにちは！
SRE (Service Reliability Engineering) の tada です。
この記事では、プロダクト開発センターで利用している SaaS のユーザー管理や権限管理を、Terraform へ移行したお話をしたいと思います。
当時の状況と課題
プロダクト開発センターでは様々なサービスを利用しています。
AWS、Datadog、GCP、GitHub、Jira、Sentry などなど。
その中で AWS、Datadog、GitHub に関しては、新しく JOIN したメンバーへの権限付与、権限の変更、ロールの払い出しなどの作業を SRE で担っています。
当時は Terraform 化されていなかったため、各種サービスの画面から対応をしていましたが、対応にはユーザーなどの削除も含まれているので、対応者には強い権限が付与されていました。
危険な変更はペアで作業を実施するなど、古典的な予防措置はとっていましたが、
- お互いの予定を調整する必要がある。
- 手作業となるためオペレーションミスの可能性が存在する。
- 強い権限を与えることで越権行為やセキュリティリスクを孕んでいる。
- 対応が俗人化しやすい。
などの課題を抱えていました。
期待する結果とゴール
抱えていた課題を解決する手段の一つとして Terraform 化をした上で、CI/CD を構築し対応ワークフローを自動化していくことが考えられます。
ユーザー管理や権限管理を Terraform 化することにより、Terraform コードを管理している Repository への Write 権限を持っていれば、誰でも対応を行えるようになります。
それにより、上で挙げた課題に対して以下のような改善が見込めます。
| 課題 | 改善されること |
|---|---|
| お互いの予定を調整する必要がある。 | Pull Request、CI/CD ベースでの対応となるため非同期に対応を行えます。 |
| 手作業となるためオペレーションミスの可能性が存在する。 | CI/CD による自動化で画面操作よりは大幅にミスのリスクが軽減されます。 |
| 強い権限を与えることで越権行為やセキュリティリスクを孕んでいる。 | Terraform を管理している Repository への Write 権限さえあれば対応できるため付与する権限を抑えることができます。 |
| 対応が俗人化しやすい。 | Terraform 化されるので Terraform 経験のあるメンバーであれば対応しやすい。 |
Terraform 化の方針
Terraform 化するにあたり、どこまでのリソースを管理下にするかスコープを決める必要があります。
もちろん全てのリソースを Terraform 化してもいいのですが、そのためにはかなりの時間が掛かります。
今回の目的は SRE で担っている保守作業の課題を解消することなので、作業が及ぶリソースにスコープを定めて対応を始めました。
AWS
- Organizations Account
- Identity Store User
- Identity Store Group
- Identity Store Group Membership
- Permission Set
Datadog
- User
GitHub
- Membership
- Team
- Team Membership
- Repository
- Repository Collaborator
対応ワークフロー
Terraform のコードは GitHub で管理し、GitHub Actions で Terraform の plan、apply を実行するように CI/CD を構築してあり、対応ワークフローは以下のようになります。
- 依頼が Slack ワークフローで届く。
- SRE メンバーが Terraform コードを修正し Pull Request を作成。
- GitHub Actions による plan の出力結果を確認。
- 別の SRE メンバーによるレビューと承認。
- Pull Request をマージし GitHub Actions で terraform apply が実行され適用完了。
- 対応完了の旨を連絡。
結果
Terraform 化を進めたことで、権限管理やユーザー管理の運用負荷が軽減されました。
また、不必要な権限を対応者に付与する必要もなく、インシデントリスクを抑える効果も得られていると思います。
ただ、SRE で管理している SaaS は様々あり、保守的な対応作業も多く存在するので、トイルの観点からそのような作業を自動化により撲滅していくことが望まれます。
次回はその辺りの話をしていきます。