GitHub ActionsからAWSを安全に操作するために、CI/CDの権限設計を見直した話
GitHub ActionsからAWSを安全に操作するために、CI/CDの権限設計を見直した話
個人開発で DevOps ポートフォリオ「terraform-hannibal」を作っています。
terraform-hannibal:
https://github.com/kmryst/terraform-hannibal
このプロジェクトでは、AWS や Terraform のリソースを作るだけではなく、GitHub Actions、GitHub OIDC、IAM Role、Terraform plan、deploy / destroy の権限分離まで含めて、実務に近いCI/CD基盤を設計しています。
今回のテーマは、GitHub ActionsからAWSを安全に操作するための権限設計です。
CI/CDは便利ですが、GitHub ActionsからAWSを操作できる経路を作るということは、設計を誤ると危険な操作経路にもなります。
PRチェックに必要な権限。
mainブランチからのdeployに必要な権限。
destroyのような破壊的操作に必要な権限。
これらは本来、同じではありません。
terraform-hannibal では、こうした操作の違いを踏まえて、GitHub ActionsからAWSへ接続する方法と、IAM Roleの分け方を見直しました。
CI/CDは便利だが、権限設計を間違えると危険になる
GitHub Actionsを使うと、Terraform plan、deploy、destroy などを自動化できます。
ただし、自動化するということは、GitHub側からAWSを操作できる経路を作るということでもあります。
もしその経路に強すぎる権限を持たせてしまうと、問題が起きたときの影響範囲が大きくなります。
たとえば、Pull RequestでTerraform planを実行する場合、本来必要なのは変更差分を確認するための読み取り権限が中心です。
一方で、mainブランチからのdeployやdestroyには、実際にAWSリソースを作成・更新・削除する権限が必要になります。
この2つを同じIAM Roleで扱ってしまうと、PRチェックの経路に不要な変更権限を持たせることになります。
terraform-hannibalでは、ここを明確に分けることを重視しました。
長期アクセスキーを置かず、GitHub OIDCを使う
GitHub ActionsからAWSへ接続する方法として、AWSアクセスキーをGitHub Secretsに置く方法があります。
しかし、長期アクセスキーは漏えい時のリスクが大きく、管理上も慎重に扱う必要があります。
そこで terraform-hannibal では、GitHub ActionsからAWSへ接続する際に、長期アクセスキーではなく GitHub OIDC を使う構成にしています。
OIDCを使うことで、GitHub Actions実行時にAWS側のIAM Roleを一時的に引き受ける形にできます。
つまり、固定のAWSアクセスキーをGitHub側に持たせず、必要なタイミングで必要なRoleを使う構成です。
これにより、GitHub Secretsに長期AWSアクセスキーを置かずに、GitHub ActionsからAWSを操作できるようにしています。
PR plan用Roleとdeploy / destroy用Roleを分ける
terraform-hannibalでは、GitHub ActionsからAWSを操作するRoleを用途ごとに分けています。
PRでTerraform planを実行するRole。
mainブランチでdeploy / destroyを行うRole。
この2つは、目的も必要な権限も違います。
PR planでは、変更差分を確認できればよいので、基本的には読み取り中心の権限で十分です。
一方で、deploy / destroyはAWSリソースを作成・更新・削除するため、より強い権限が必要になります。
このため、PR plan用Roleには変更権限を持たせすぎず、deploy / destroy用Roleとは分離する設計にしました。
これは、被害範囲を小さくするための設計です。
仮にPRチェック側で問題が起きても、AWSリソースを直接変更できる経路にしない。
mainブランチでの実行と、PRでの検証を同じ権限で扱わない。
こうした分離により、CI/CDの利便性を保ちながら、不要なリスクを減らすことを意識しています。
fork PRではAWS認証を走らせない
公開リポジトリでは、forkされたPull Requestをどう扱うかも重要です。
fork PRは、自分が管理していないブランチからコードが送られてくる可能性があります。
そのため、fork PRに対して不用意にAWS認証を走らせると、意図しないコードにAWS権限が渡るリスクがあります。
terraform-hannibalでは、fork PRではAWS認証が走らないようにし、Pull Requestの種類によって実行できるチェックを分ける設計を意識しています。
すべてのPRで同じ処理を実行するのではなく、以下のように分けて考えています。
・安全に実行できる静的チェック
・AWS認証が必要なTerraform plan
・mainブランチでのみ許可するdeploy / destroy
CI/CDでは、「どのイベントで、どの処理を、どの権限で実行するか」を分けることが重要だと感じました。
「自動化すること」と「何でも自動で動かすこと」は違う
CI/CDでは、自動化すること自体が目的になりがちです。
しかし、実際には「どの操作を、どの条件で、どの権限で実行するか」を決めることのほうが重要です。
terraform-hannibalでは、以下のような考え方を取っています。
・PRでは、変更内容をレビューできるようにする
・PR planでは、必要以上に強い権限を持たせない
・deploy / destroy は main ブランチ側の明示的な操作に寄せる
・GitHub OIDCを使い、長期AWSアクセスキーをGitHubに置かない
・fork PRではAWS認証を走らせない
・IAM Roleを用途ごとに分け、影響範囲を小さくする
これは、単にTerraformやGitHub Actionsを使う話ではありません。
変更の入口、認証経路、IAM権限、ブランチ条件、実行タイミングをまとめて設計する話です。
現在の terraform-hannibal で実装していること
terraform-hannibalでは、GitHub Actionsを使ったCI/CDだけでなく、Issue / PR / CI / IAM / Terraform plan をつなげて、変更管理の流れとして設計しています。
たとえば、Pull RequestではTerraformの差分を確認し、変更内容をレビューできるようにしています。
また、GitHub ActionsからAWSへ接続する際には、GitHub OIDCを使い、長期アクセスキーをGitHub側に置かない構成にしています。
さらに、PR plan用のIAM Roleと、deploy / destroy用のIAM Roleを分けることで、用途に応じた権限境界を作っています。
このほか、Terraform fmt / validate、TFLint、Trivy Config、Gitleaks などのチェックも組み込み、IaC・セキュリティ・シークレット混入の観点から変更を確認できるようにしています。
個人開発ではありますが、単に「動くものを作る」だけではなく、実務のチーム開発や運用を想定して、変更を安全に積み重ねられる仕組みを作っています。
DevOpsで重要なのは、速さと安全性を両立すること
CI/CDを整える目的は、単にデプロイを速くすることだけではありません。
安全に変更できること。
レビューしやすいこと。
問題が起きても影響範囲を小さくできること。
誰が、どの経路で、どの権限を使ったのかを追えること。
こうした条件を満たしてこそ、チームで継続的に変更を積み重ねられる環境になります。
TerraformでAWSリソースを作れることは重要です。
GitHub ActionsでCI/CDを組めることも重要です。
しかし、それだけでは安全な運用にはなりません。
PRでは何を確認するのか。
mainブランチでは何を許可するのか。
AWS認証はどの条件で走らせるのか。
IAM Roleはどの単位で分けるのか。
destroyのような破壊的操作をどう扱うのか。
こうした設計判断も、DevOpsでは重要な領域だと考えています。
技術的な詳細
今回の考え方は、Zennの記事にまとめています。
https://zenn.dev/kmryst/articles/moneyforward-github-aws-cicd-blast-radius
この記事では、GitHub ActionsからAWSへ入る経路、OIDC、IAM Role分離、PR planとdeploy / destroyの権限境界、fork PRでAWS認証を走らせない理由などを整理しています。
また、GitHub ActionsのAWSキーをやめてOIDCへ移行した話は、こちらの記事にもまとめています。
https://zenn.dev/kmryst/articles/github-actions-aws-oidc-migration-1
今後の方向性
今後も terraform-hannibal では、CI/CDの利便性を高めるだけでなく、権限分離、監査性、コスト、セキュリティ検知、運用負荷のバランスを見ながら改善していきたいと考えています。
自動化は、便利さだけを追うと危険になります。
一方で、慎重になりすぎると、開発の速度が落ちます。
その間で、どこまでを自動化し、どこで人間の判断を残すか。
どの操作にどの権限を与え、どこで止めるか。
問題が起きたときに、どこまで影響を閉じ込められるか。
そうした設計判断を積み重ねながら、DevOps / SRE / Platform Engineering 領域で価値を出せるエンジニアを目指しています。
