TerraformのCI/CDって結局どうしたらいいの？

Transcript

1. の って結局どう したらいいの？ Terraform CI/CD 交流会！#4 TechBull mini LT& クラシル株式会社 SRE kaitobq
2. 自己紹介 kaito / @kaitobq クラシル株式会社 新卒SRE（インターンから数え て2年目） やってること Enabling / ID ィ周り 基盤の運用 / CI・CD / セキュリテ 今日は terraform plan (CI) に絞って、リスクと対策を整理した話をします
3. CI/CD 環境は認証情報の宝庫 の CI/CD 実行環境にあるもの tfstate の Read / CI環境に付与したクラウド権限 / 各種 credentials / etc. Terraform 任意コード実行の経路 悪意ある provider と plan(CI) の違い apply： 承認フローが組まれていることが多い（適切な承認フロ ーを組む必要はある） plan： クラウドの権限を持ち、PR 上で動く apply(CD) data "external" リポジトリの権限漏洩 etc. PR を出すだけで、CI(plan) 実行環境の権限を悪用できる構成になりやすい どんな対策をすれば防げる？
4. 周りのテックブログを漁ってみた Terraform CI 対策 引用元 信頼できないコードで本番環境の plan を回さない plan 実行前に承認フェーズを挟む レビュー済み provider を実行イメージに埋め込み、 -plugin-dir とハッシュ照合 で固定する external を Conftest・Rego でブロックする plan / apply でロールを分ける。 plan ロールを最小権限にする tfstate Terraform CI code execution restrictions Mercari Terraform CI code execution restrictions Mercari Terraform CI code execution restrictions Mercari を分離した権限設計について考えてみる Fenr を分離した権限設計について考えてみる Fenr CI/CD ir CI/CD ir に平文の秘密を残さない（ephemeral / write-only） 実行を記録し、後から検知・調査できるようにする Terraform Plan RCE Alex Kaskasoli NEW!! に平文を残さずに秘密情報を管理する tfstate q Takumi Runner / cicd-sensor kaitob
5. 多い！
6. これらが全て満たせていればいいの？ そんなことはないらしい OWASP Top 10 CI/CD Security Risks と突き合わせてみる
7. OWASP Top 10 CI/CD Security Risks CI/CD 環境の固有リスクを10項目に整理したもの。各項目に Recommendations（推奨事項）がある 7 / 10 先ほどの8つの対策は OWASP の7つのリスクカテゴリに関連 各カテゴリには複数の推奨事項があり、 考慮すべき項目は合計58件 カバーしていない項目も、全部やらないといけない？
8. 全部やらないといけないのか？ 件全てをいきなり満たそうとするのは現実的ではない 58 テックブログから集めた8つの対策は、 CI 上での Terraform plan を守るためのベースラインにはなるのでは？ これらを分類すると
9. 分類する 対策 信頼できないコードで本番環境の plan を回さない plan 実行前に承認フェーズを挟む レビュー済み provider を実行イメージに埋め込み、 -plugin-dir とハッシュ照合で固定する external を Conftest・Rego でブロックする plan / apply でロールを分ける。 plan ロールを最小権限にする tfstate に平文の秘密を残さない（ephemeral / write-only） 実行を記録し、後から検知・調査できるようにする OWASP Top 10 CI/CD 効いている場所 ① 任意コード実行を 防ぐ ② 実行されたときの 被害を狭くする ③ 検知・調査 できるようにする の推奨事項58件も、大体この3つに分類できる
10. 結局どうしたらいいの（個人的な意見） リスク ＝ 発生確率（ ） 被害の大きさ（ ） Likelihood × Impact ── OWASP Risk Rating Methodology 対策 効いている場所 信頼できないコードで本番環境の plan を回さない plan 実行前に承認フェーズを挟む ① 任意コード実行を 防ぐ レビュー済み provider を実行イメージに埋め込み、 -plugin-dir とハッシュ照合で固定する external を Conftest・Rego でブロックする ⇒ 発生確率を下げる。やることが無限で、0 にはならない コスパがいい plan / apply でロールを分ける。 ② 実行されたときの plan ロールを最小権限にする 被害を狭くする tfstate に平文の秘密を残さない（ephemeral / write-only） ⇒ 被害の大きさを下げる。やることが限られ、確実に効く 実行を記録し、後から検知・調査できるようにする ③ 検知・調査 できるようにする 発生確率は 0 にはできない → ③ 起きたことが見える状態にしておく Takumi Runner / cicd-sensor
11. まとめ リスク ＝ 発生確率（Likelihood）× 被害の大きさ（Impact） 発生確率は 0 にできない → 被害の大きさを下げる方が確実にリスクを低減できる OWASP Risk Rating Methodology からやるなら まず 被害の大きさ（Impact）を抑える（②）。そのうえで、組織の成熟度と事業内容に応じて予防（①）、 検知・調査（③）を重ねていく 予防は積み上げ続けられるので、OWASP Top 10 CI/CD を一覧として使い、優先順位と「やらないこと」 を決める 0 どれか1つではなく 多層防御！