【要約】【CDK for Go】GitHub Actions OIDC + CDKで最小権限デプロイロールを設計 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者がGitHub ActionsからAWSリソースを操作する際、認証情報の管理に深刻な課題を抱えている。従来のIAMユーザーとアクセスキーを用いる手法では、以下の問題に直面する。
- ・長期クレデンシャルの漏洩リスク。Secretsから流出した際、失効まで有効であり危険である。
- ・ローテーション運用の形骸化。定期的なキーの差し替えは、運用負荷が高く継続が困難である。
- ・権限設定の不備。Actionを絞ってもResourceを「*」にすると、アカウント全体への影響が出る。
// Approach
著者は、GitHub OIDCによる一時的な認証と、CDKを用いた厳格な権限定義による解決策を提案している。具体的なアプローチは以下の通りである。
- ・GitHub OIDC ProviderをAWSに作成し、短命のIDトークンを利用する。
- ・Trust Policyの
sub条件を用い、特定のリポジトリやブランチからのアクセスのみを許可する。 - ・IAMポリシーにおいて、ActionだけでなくResourceのARNを特定リソースに固定する。
- ・CDKのユニットテストを用い、意図しない権限変更を検知するガードレールを構築する。
// Result
この設計を導入することで、開発チームはセキュリティと運用の容易性を同時に獲得できる。具体的な成果は以下の通りである。
- ・Secretsに機密情報を保持せず、認証情報の漏洩リスクを根本から排除できる。
- ・権限の変更がテストによって可視化され、意図しない権限昇格を未然に防げる。
- ・万が一のクレデンシャル流出時も、影響範囲を特定のリソースのみに限定できる。
Senior Engineer Insight
> 現場視点では、Action（動詞）以上にResource（目的語）を絞る設計が極めて重要だ。Actionを絞ってもResourceが「*」であれば、攻撃の爆発半径は防げない。また、CDKによる権限のユニットテストは、単なる検証を超えた「組織的なガードレール」として機能する。権限変更をコードの差分として強制的にレビュー対象に含める手法は、大規模な開発組織において、セキュリティ事故を未然に防ぐための極めて実戦的なプラクティスである。