Upgrade to Pro — share decks privately, control downloads, hide ads and more …

コンパウンドスタートアップのためのスケーラブルでセキュアなInfrastructure as ...

コンパウンドスタートアップのためのスケーラブルでセキュアなInfrastructure as Codeパイプラインを考える / Scalable and Secure Infrastructure as Code Pipeline for a Compound Startup

2024/04/16 at AWS知見共有会 - 運用のスケーラビリティとセキュリティ
https://timeedev.connpass.com/event/314564/

その後GitHubから発表された新機能Push rulesについて、この発表内容に関連付ける形でブログ記事を出していますので、そちらも併せて参照してください。
https://tech.layerx.co.jp/entry/scalable-and-secure-infrastructure-as-code-pipeline-for-a-compound-startup

Yuya Takeyama

April 16, 2024
Tweet

More Decks by Yuya Takeyama

Other Decks in Technology

Transcript

  1. © LayerX Inc. 2 はじめに • 本日の発表では、Infrastructure as Codeは全てIaCと省略します •

    IaCパイプラインは「Infrastructure as CodeツールのためのCI/CDパイプ ライン」を意味します • 本資料中に出てくるGitHubリポジトリ名は、いずれも仮称です はじめに
  2. © LayerX Inc. 4 自己紹介 竹山雄也 (@yuya-takeyama) • 株式会社LayerX •

    コーポレートエンジニアリング室 • 2023年9月入社 • 前職はSRE • 浅草在住 • 趣味: メタル、麻雀、飲み歩き、散歩、ランニング
  3. © LayerX Inc. 9 IaCパイプラインによって目指したい状態 LayerXにおけるIaCパイプライン概要 • チーム間での依頼という形をなるべく避けて、必要なリソースの調達や設定の変 更を自分たちで行えるようにする (セルフサービス化)

    ◦ サイクルタイムの向上 ◦ ノウハウを持つべき人に蓄積 • リソースに応じて、適切な形でのレビュー、ガバナンスの適用 ◦ 統一性の高いワークフローにより、アジリティとセキュリティを両立し、バランスを取る ◦ 「適切な形」は絶えず変化するので、適応できるようにする
  4. © LayerX Inc. 10 • corp-infra ◦ コーポレートエンジニアリング室が管理するmonorepo ◦ 会社全体の共通部分に関わるAWS、Google

    Cloud、Microsoft Entra ID、Datadog等 ◦ GitHub Actions上でTerraformを利用 • bakuraku-infra ◦ バクラク事業部DevOpsチームが管理するmonorepo ◦ バクラク事業部に紐づくAWS、GCPリソース ◦ AWS CodeBuild上でTerraformを利用 • その他事業部の管理するパイプラインもいくつか存在 LayerXにおけるIaCパイプライン (リポジトリ) LayerXにおけるIaCパイプライン概要
  5. © LayerX Inc. 11 LayerXにおけるIaCパイプラインのポイント LayerXにおけるIaCパイプライン概要 • 全社的なリソースはコーポレートエンジニアリング室が管理 (corp-infra) •

    個別の事業・プロダクトに閉じたアカウント・リソースは各事業部に委譲 ◦ そのためのパイプラインも専任のチームがオーナーシップを持つ ◦ いずれもTerraformを使いつつも、細かい使用技術は異なる • それぞれのリポジトリはmonorepoになっており、同一事業内でプロダクトが 増えても、リポジトリやIaCパイプラインは増えない ◦ 効率的に事業の拡大を支えることができる
  6. © LayerX Inc. 13 運用のスケーラビリティのために目指していること • 適切な単位(VPC、DNS、SSO等)や環境でtfstateを分割する ◦ drift等により、後続Pull Requestのマージができない状況を減らす

    ◦ Terraform等のツール類のアップデートを段階的に行えるようにする ◦ matrix buildによる動的なパイプラインでの並列実行が必要 • 各種ツールやTerraform Providerの自動アップデート ◦ 常にセキュリティ上望ましい状態を最小の労力で維持 ◦ Renovateを活用 • かつ、これらの仕組みをOSSを活用して最小のコストで実現 コーポレートエンジニアリング室におけるIaCパイプライン (運用のスケーラビリティ)
  7. © LayerX Inc. 14 tfactionの導入・移行 コーポレートエンジニアリング室におけるIaCパイプライン (運用のスケーラビリティ) • 当初は独自のMakefileを利用したパイプラインだった ◦

    Terraform、tfcmt、tfsec、secretlint等 • かつ、全てのクラウドプロバイダー・それぞれの環境が一つのtfstateに全部入 りになっていた • tfactionというOSSを導入し、段階的に移行を進めている
  8. © LayerX Inc. 15 tfactionの紹介 コーポレートエンジニアリング室におけるIaCパイプライン (運用のスケーラビリティ) • GitHub ActionsでTerraformのIaCパイプラインを構築するためのAction

    群 • 作者: @suzuki-shunsukeさん • build matrixによる動的なパイプライン • Pull Requestへのコメントによりplanをわかりやすく表示 (tfcmt) • aqua、trivy、tflint、conftest等のツールの統合 • Renovateとの統合による自動アップデートの支援 • などなど...
  9. © LayerX Inc. 16 • 前職でも利用していた ◦ 中身もある程度把握している • 作者の

    @suzuki-shunsuke さんとは前職で同じチームで働いていた ◦ そもそも前職における課題を解決するために作られたものであり、 その背景や過程にも関わっていた ◦ お互いの転職後も困ったら相談できるぐらいの距離感 • IssueやPull Requestを通じてのcontributionの経験 • 以上から、何か問題が起きても最悪自分で何とかできるだろうという自負 tfaction導入の背景 コーポレートエンジニアリング室におけるIaCパイプライン (運用のスケーラビリティ)
  10. © LayerX Inc. 19 IaCパイプラインのセキュリティとは? CI/CD パイプラインは重要であると同時にリスク の高いシステム・コンポーネントである。 コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ)

    デジタル庁による「CI/CD パイプラインにおけるセキュリティの留意点に関する技術レポート」より引用 https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/504 c3218-1eb0-4287-ba16-01641fdc038c/d377749c/20240329_policies_developmen t_management_outline_08.pdf
  11. © LayerX Inc. 20 IaCパイプラインが抱えるセキュリティリスク • IaCパイプラインはクラウドアカウントや各種リソースへの破壊的権限を持つ ◦ 攻撃者に悪用されれば、サービス復旧不可能な状態への破壊も可能 ◦

    マルウェアの配布等、エンドユーザーに直接的に影響を与えることも可能 • 重要度の高いクレデンシャルへのアクセスが可能・持っていることが一般的 ◦ 攻撃者に悪用されれば、更なる侵入(ラテラルムーブメント)や情報漏洩に繋がることも • CI/CDプラットフォームや関連ツール自体が攻撃される可能性 ◦ ツール・プラットフォームへの依存はそれ自体がセキュリティ上のリスクに繋がる (サプライチェー ンリスク) コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ)
  12. © LayerX Inc. 21 安全なIaCパイプラインとは コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ) • セキュアなクレデンシャルを利用、またはセキュアにクレデンシャルを保管する •

    レビューを通っていない変更をマージさせない • レビューを通っていない処理を実行させない • 必要以上のツール類を利用しない • 安全なインストール手順を利用する
  13. © LayerX Inc. 22 • OpenID Connectによる動的なクレデンシャルの利用が望ましい ◦ 静的なAPI Key・API

    Tokenの利用を極力避ける ◦ terraform planとterraform applyとで権限の分離は必須 ◦ terraform apply用の権限はprotected branchで保護されたmainブランチ等のみに許可 • OpenID Connectが利用できなければAWS Secretes Managerを利用 ◦ GitHub ActionsのOrganization Secret/Repository Secretは利用しない ◦ planとapplyとで権限・API Keyの分離は必須 ◦ KMS key policyやresource-based policyにより、特定のIAM Roleのみにアクセスを制限 セキュアなクレデンシャルを利用、またはセキュアにクレデンシャルを保管する コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ) ここができていないと、IaCパイプラインにPull Requestを作れる 社員1名のアカウント奪取で攻撃が成立する可能性!!
  14. © LayerX Inc. 23 レビューを通っていない変更をマージさせない コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ) • レビューなしでのマージ (≒terraform

    apply) を許可することは、インフラへ の変更を何でも許可することを意味する • Protected branchの以下の設定を有効にする (または検討する) ◦ Require a pull request before merging ◦ Require approvals ◦ Require review from Code Owners ◦ Require approval of the most recent reviewable push ◦ Require status checks to pass before merging ◦ Require branches to be up to date before merging ◦ Require signed commits ◦ などなど
  15. © LayerX Inc. 24 レビューを通っていない処理を実行させない • on: pull_requestでterraform planを実行するWorkflowを作らない ◦

    Workflowを変更してPull Requestを作成するだけで、任意の処理が実行できてしまう • 代わりにon: pull_request_targetを利用する ◦ レビュー済みのdefault branch上のWorkflowが実行される ◦ sts:AssumeRoleWithWebIdentityのConditionでもpull_request_targetのみに絞る • ブランチ内のスクリプトを実行してはならない ◦ pull_request_targetを利用しても、スクリプトはブランチ内の未レビューのものが実行される ◦ どうしてもやる場合は、default branchから取得したり、別repoのレビュー済みブランチから コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ) 参考: GitHub Actions でスクリプト等の改竄を防ぐ https://zenn.dev/shunsuke_suzuki/articles/prevent-tamper
  16. © LayerX Inc. 25 • ツール類の利用はそれ自体がセキュリティリスクを持つ ◦ 参考: CodecovのBash Uploader

    scriptへのポイズニング https://about.codecov.io/security-update/ • 信頼できない開発者のsetup-*-action等を雑に利用しない ◦ aquaでのchecksumの検証を有効にしてインストールする • ただし、それでも完璧ではないことは理解しておく ◦ 攻撃の意図を持つ者が信頼され、正当な手続きにより不正なソフトウェアがリリースされたら? ◦ 参考: XZ Utilsの脆弱性 CVE-2024-3094 についてまとめてみた https://piyolog.hatenadiary.jp/entry/2024/04/01/035321 必要以上のツール類を利用しない/安全なインストール手順を利用する コーポレートエンジニアリング室におけるIaCパイプライン (セキュリティ)