【要約】AdministratorAccessが使えない環境でCDKをbootstrapする [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
エンタープライズ環境のエンジニアが、社内の厳格なIAMポリシーによりCDKの導入を阻まれる問題に直面する。cdk bootstrap実行時に作成されるCloudFormationExecutionRoleが、デフォルトでAdministratorAccessを持つことが原因である。具体的には以下の制約が障壁となる。
- ・SCPやIAMガードレールにより、AdministratorAccessの付与が禁止されている。
- ・強い権限を持つIAMロールに対し、Permission Boundaryのアタッチが強制されている。
- ・特定のIAMアクションやリソースの作成が、組織全体で制限されている。
// Approach
著者は、セキュリティ制約の強度に応じて選択可能な3つの技術的アプローチを提案している。これらは、標準機能の利用からテンプレートの直接編集へと段階的に高度化する。
- ・対策1：
--cloudformation-execution-policiesフラグを用い、AdministratorAccessの代わりに必要なマネージドポリシーや自作ポリシーを割り当てる。 - ・対策2：
--custom-permissions-boundaryフラグを用い、AdministratorAccessを維持しつつ、Denyベースのガードレールを境界として設定する。 - ・対策3：Bootstrapテンプレートを
npx cdk bootstrap --show-templateで取得・修正し、全IAMロールへの境界適用やSynthesizerの変更を行う。
// Result
これらの手法を用いることで、開発者は組織のガバナンスを遵守しながらCDKによるインフラ自動化を実現できる。具体的な成果は以下の通りである。
- ・セキュリティ部門の要求を満たしつつ、CDKのデプロイを成功させられる。
- ・マネージドポリシーとカスタムポリシーを組み合わせることで、運用コストを抑えた現実的な権限管理が可能になる。
- ・テンプレートのカスタマイズにより、標準のbootstrap機能では対応できない高度な権限制御を実現できる。
Senior Engineer Insight
> 実戦では、最小権限の追求が開発体験を著しく損なうリスクを考慮すべきだ。全てのActionを個別に許可するのは、CDKの抽象化の恩恵を打ち消すほどメンテナンスコストが高い。現実的な解は、マネージドポリシーで土台を作り、IAMやSSMなど絞り込み可能な対象のみをカスタムポリシーで制御するハイブリッド構成だ。また、テンプレートのカスタマイズは、組織全体のガードレールとして機能するが、CDKのバージョンアップ時の影響を考慮した運用設計が不可欠である。