Terraformを用いたJamf Pro構成のIaC, GitOps化への挑戦

2026-04-16開催 JMUG （Jamf Macadmin User Group （ジェイマグ）） #36 LT資料です。
デバイス管理基盤であるJamf Proの構成管理について、手順書ベースの手作業（ClickOps）からTerraform + GitOpsへ移行した事例を紹介します。Jamf APIをパイプライン上で安全に扱うためのセキュアなCI/CD設計（権限分離、アクセス制御）や、既存リソースをコード化（Import）する際の運用Tipsも解説しています。

Transcript

1. 2026年4月16日 | JMUG #36 Terraformを用いた Jamf Pro構成の IaC, GitOps化への挑戦 株式会社メルカリ Engineering Manager of Enterprise Security Yu Sasaki 1
2. 自己紹介 2023.04 2024.01 2026.03 Security Management Security Engineer Engineering Manager リスクアセスメント・セキュリティ ポリシー実装・運用自動化に従事 Enterprise Security teamを統括 ポリシー策定を推進 Yu Sasaki (@yu) 2
3. 本日のテーマ 1 2 3 従来のJamf Pro変更管理運用の課題と「 GitOps」の導入 手順書ベースの手作業（ClickOps）や権限管理が抱えていた課題と、Terraformを 用いたPR駆動の自動化フローへの移行。 セキュアな CI/CDアーキテクチャ 強力な権限を持つJamf APIをパイプライン上でいかに安全に扱うか。CI/CDの権限 分離やSecret Managerを用いた厳格なアクセス制御。 既存環境からの移行と運用の Tips ゼロからではなく既存リソースを効率的にコード化（Import）する手法、Jamf特有の 差分ノイズへの泥臭い対処法、導入効果。 3
4. 課題認識 従来のJamf Pro運用が抱えていた課題 4
5. 手作業（ ClickOps）の課題 • • 手順書ベースの手作業（ ClickOps）による運用負荷とオペミスのリスク 「誰が・何を・なぜ」変更したか（所謂 5W1H）がSlackやNotion、申請ツールに散在し、後から辿るコ ストが増大 オペミスのリスク 見出し • テスト→本番 • 手動での設定 レビュープロセス 変更コンテキストの散在 • 手順書, WebUIを目検 • Notion, Google Docsなどの文書 • Slack上のやり取り 5
6. 権限管理と監査の課題 プロダクト環境には厳格な権限管理を敷いている一方、会社環境のデバイス管理基盤に強い権限が常時 配られているのは、アタックサーフェスマネジメントの観点で課題。 高権限付与のリスク Attack Surfaceの拡大 定常メンテナンスのために、常 時高い操作権限を持つアカウ ントをオペレーターに付与し続 ける必要あり Jamf Pro管理者の端末・アカ ウントが侵害された場合、従 業員デバイス全体に影響を及 ぼすリスク（マルウェア配布等 にも悪用され得る） 変更履歴機能の制約 一部のJamf Proコンポーネ ントについては詳細な変更履 歴を保持しない。 (例: 構成プロ ファイル) 6
7. 改善策 IaC(Infrastructure as Code)とGitOps導入 7
8. TerraformとPR駆動の変更管理への移行 (1) • • オープンソースの Terraform provider（jamfpro）を活用し、構成をコード（ IaC）化 「手順書」から「コード差分と terraform planの出力」を一次情報とするレビュー体制へ移行 ④PRを“main”ブランチへマージし terraform applyを自動実行 ①ローカルの Terraform ファイルを 編集 GitOpsによる 構成管理 ③Planの結果を確認し PRのレビュー を行う ②GitHub上でPR(Pull Request)を 作成しterraform planを自動実行 8
9. PR駆動の変更管理の流れ (1) 誰が変更するのか。 (Who) 何を変更するのか。 (What) 何故変更するのか。 (Why) 9
10. PR駆動の変更管理の流れ (2) 変更の詳細 (What) • どの行でどの文言が変更されたか • 変更前・変更予定が分かりやすい UI 10
11. PR駆動の変更管理の流れ (3) リソースの更新・作成・削除影響を自動で確認 何時(When)誰が(Who)この変更を承認したかの 記録を残せる main ブランチへのマージ 11
12. PR駆動の変更管理の流れ (4) 本番環境へ変更が完了した日時 (When) とその内容について確認可能。 12
13. セキュアな CI/CD構成 Special Thanks: @south 13
14. GitHubの main branchを守る必要性 • • リポジトリへの書き込み権限を持っている人は誰でも PRを送出可能 重要な構成(Terraform ファイル)を意図せず、変更出来てしまうリスクを低減 (ご参考) https://engineering.mercari.com/blog/ent ry/20241217-github-branch-protection/ 14
15. (1)CODEOWNERSによる変更範囲と承認責務の紐づけ • • ディレクトリ構造をシステムのレビュー境界と一致させる .github/CODEOWNERS ファイルとbranch protection活用し、特定のディレクトリ変更時に担当 チーム（例：Security team）の承認を強制 (例) 何れのファイルも該当チームで所 管 Dependabot関連のPRは自動承認 出来るようにする措置 15
16. (2)CI/CDの統制と権限分離 • • terraform plan (事前確認) と terraform apply (本番反映) のワークフローを完全に分離 「承認済みの変更だけが反映される」状態を担保 GitHub Actions workflows ├──plan-production.yml (PR作成時) → Jamf構成は読み取り専用 └──apply-production.yml (Merge後) → 反映(書き込み)権限 ※ applyは READ/CREATE/U PDATE/DELETE全 て必要なため付与す る権限は多くなる 16
17. (3)パイプラインを保護する Jamf Pro APIシークレット管理 • • • OIDC認証: GCPへのアクセスは静的なクレデンシャルを用いず、Workload Identityで認証(短寿命トークン) 最小権限の徹底 : Jamf ProへアクセスするPlan workflow時は読み取り専用のAPIシークレット、Apply時はCRUD （書き込み）用のシークレットをGoogle Secret Managerから取得 IAMによるワークフロー単位の制限 : google_project_iam_member およびworkload identityのAttribute mappingsによりGitHubから発行されたIDトークンのクレーム（claim）を検証し、「特定のGitHub Actions workflowが実行された場合のみ」認証情報を参照できるよう制限し、権限の不正利用を防止 GitHub Google Cloud PR Trigger Run ‘plan’ workflow Request Read-Only Secret GCP Workload Identity Federation (OIDC) Merge to Main Run ‘apply’ workflow Request Write Secret GCP Secret Manager Jamf Pro Configurat ion Profile, Policy, Script, Computer Group, etc… Jamf Pro APIへアクセス 17
18. CI/CD乗っ取りを防ぐセキュアな IAMバインディング • • どのブランチで（ ref）、どんなイベントで（ event_name）、どのワークフローファイルが動いたか （workflow_ref）まで条件を縛る 万が一悪意のあるユーザーが独自のワークフローを組んでシークレットを盗もうとしたり、意図しない イベントでCIを走らせても、 Google Cloud側ではじく 参照先CWIDP で利用してい るマッピング設定の一部 CWIDP の attribute_mapping で属性を定義し、それを条件と して IAM バインディングでアクセス制御を行っている 18
19. 移行アプローチと運用 Tips 19
20. 既存リソースの効率的なコード化（ Import） • • • 最初から全てを管理しようとしない すでに存在する大量の設定を「ゼロから書く」と移行が頓挫する Import Block や terraform plan -generate-config-out コマンドを活用し、 Jamf Pro上の既存 設定から直接 .tfファイルを自動生成して Stateに取り込む 20
21. 運用Tips(1)(2) 事象 対処例 1 構成プロファイルを初回アップ ロードした際、要素が不足してい るとJamf Pro側で自動的に PayloadIdentifier などの要素が 付加される。 • • 予め既存のplistを参考に作成 次回差分発生時に追いつき更新 2 Policy更新時、Self Serviceに関 する属性差分など、 UI上の変更 と一致していてもコード上では差 分が発生する場合がある。 (その後のprovider 改修で現時 点では解消済み ) • ワークアラウンドとして、関係者で該当差分が発生する 旨認識合わせ 21
22. 運用Tips(3): CI/CDを複数テナントで再利用しスケールする Plan, Apply それぞれのワークフローにおいて、テナント毎の固有値を変数化し、共通処理と個別処理を 分ける Sandbox テナント plan-sandbox.yml Production テナント • • • *.tf working dir Instance URL Google Secret Manager: secret name 共通処理 plan-reusable.yml apply-reusable.yml plan-production.yml 22
23. 導入効果・今後の展望 23
24. 導入効果（ GitOpsがもたらした変化） PR-Drivenな自動反映による効率化の一方で、権限管理の高度化が今後の焦点となる。  ClickOpsからの解放 手動作業を削減し PRベースの自動反 映へ。複数チームとの共管も容易に。  監査・トラブルシューティン グの容易化 変更履歴の可視化により、情報連携や 事象発生時の調査のし易さを実感  権限統制の課題 導入即最小化とはならず、 JIT等の別途 仕組みが必要 24
25. 今後の展望 1 Jamf Platform APIへの対応 (2026-04-14 Beta公開) 2 管理対象の Jamfコンポーネントの拡大 3 GitOps運用文化の浸透 Blueprint、Compliance Benchmarksへの対応 Jamf Proを利用する関連チームが利用しやすい環境の整備 25
26. 質疑応答 26
27. ご清聴ありがとうございました 27