前回の記事では、Infrastructure as Code の基礎と、Terraform を使用して Jamf Pro と Jamf Protect の設定を管理する方法について説明しました。まだお読みになっていないのであれば、インストール、プロジェクト構造、状態管理に関する内容が含まれているため、最初に確認することをお勧めします。
今回は、最近パブリックベータに入った Jamf Platform API に焦点を当てます。これらの API は、Jamf Pro および Jamf Protect と並んで配置される新世代の Jamf マイクロサービスを動かしており、blueprint、Compliance Benchmark、デバイスグループが含まれます。これらのリソースをコードとして管理できる専用の Terraform プロバイダーを構築しました。
Jamf Platform マイクロサービス用に専用プロバイダーが必要な理由
Jamf Platform API は、Jamf Pro Classic API および Pro API とは異なる API サーフェスです。Jamf Pro プロバイダーで管理するリソースとは異なる機能を動かし、別の認証情報セットを介して地域別 API ゲートウェイ (us.apigw.jamf.com、eu.apigw.jamf.com、または apac.apigw.jamf.com) に対して認証します。
Blueprint を使用すると、デバイスグループの目的の設定状態を定義し、単一の操作でデプロイできます。Compliance Benchmark を使用すると、macOS Security Compliance Project (mSCP) から業界標準のセキュリティベースラインを適用し、フリートがどの程度対応しているかを監視できます。デバイスグループを使用すると、プラットフォームレベルでデバイスを整理およびターゲット化する方法が提供されます。これらはすべてファーストクラスの機能であり、管理するリソース用に特別に設計されたスキーマを備えた独自のプロバイダーが必要です。
Jamf Pro コンソールを通じて blueprint と benchmark を管理している場合は、テナント全体でセットアップを再作成したり、時間の経過に伴う変更を追跡したりするには多くのクリックが必要であることをご存じでしょう。このプロバイダーを使用すれば、設定全体が Git に存在し、コードレビューを通過し、必要な場所に一貫して適用されます。
何がカバーされていますか?
プロバイダーは 3 つのリソース、12 のデータソース、3 つのリストリソース、および 4 つのデバイスアクション を備えています。主な領域は以下のとおりです:
Compliance Benchmark Engine - CIS Level 1 および 2、NIST 800-53 (Low、Moderate、High)、DISA STIG を含む mSCP ベースラインに対して compliance benchmark を作成および管理します。個別のルールを有効または無効にし、Organization-Defined Values (ODV) をカスタマイズし、benchmark を特定のデバイスグループにターゲット化できます。データソースを使用すると、利用可能なベースライン、ルール、および既存の benchmark をクエリできます。
Blueprint - ソフトウェア更新の実装、ソフトウェア更新設定、パスコードポリシー、Safari 設定、ブックマークと拡張機能、ディスク管理、オーディオアクセサリ設定、数学設定、サービスのバックグラウンドタスク、サービス設定ファイル、レガシーペイロード、カスタム DDM 宣言に対応する、デバイス設定 blueprint を定義します。各 blueprint は 1 つ以上のデバイスグループをターゲット化し、コードとしてデプロイまたはアンデプロイできます。データソースを使用すると、既存の blueprint と利用可能な blueprint コンポーネントをクエリできます。
デバイスグループ - コンピューターとモバイルデバイス用のスマートおよび静的デバイスグループを作成し、スマートグループの条件ベースのメンバーシップルール、静的グループの明示的なメンバーリストを使用します。これらのグループは benchmark と blueprint によってターゲット化される際に参照されます。
Unified Inventory - プラットフォームレベルで個別デバイスとデバイスリストをクエリするための読み取り専用データソース。
デバイスアクション - 管理対象デバイスに対する消去、再起動、シャットダウン、およびアンマネージ操作用の Terraform 1.14+ action。
すべてのリソースは完全な CRUD 操作と terraform import をサポートしています。
はじめに
入門記事に従った場合は、Terraform がインストール済みであり、プロジェクトの構成方法について基本的な理解を持っているはずです。ここでのステップは似ています。
1. Jamf Platform API 用の API 認証情報を作成する
Jamf Account にアクセスし、管理するリソースに必要なアクセス許可を持つ API クライアントを作成します。Jamf Developer ポータルの Getting Started ガイドでは、このプロセスについて説明しています。
2. プロバイダーを設定する
プロバイダーを Terraform 設定に追加します:
terraform {
required_providers {
jamfplatform = {
source = "Jamf-Concepts/jamfplatform"
version = "~> 0.15.0"
}
}
}
provider "jamfplatform" {
base_url = var.jamfplatform_base_url
client_id = var.jamfplatform_client_id
client_secret = var.jamfplatform_client_secret
tenant_id = var.jamfplatform_tenant_id
}
環境変数を使用してプロバイダーブロックをシンプルに保つこともできます:
export JAMFPLATFORM_BASE_URL="https://us.apigw.jamf.com"
export JAMFPLATFORM_CLIENT_ID="your-client-id"
export JAMFPLATFORM_CLIENT_SECRET="your-client-secret"
export JAMFPLATFORM_TENANT_ID="your-tenant-id"
これらの認証情報が Git リポジトリに保存されないようにしてください。terraform.tfvars ファイルを使用して .gitignore に追加します。
3. リソースを定義する
高い影響を与える例をいくつか説明します。
デバイスグループ
benchmark または blueprint を作成する前に、それらをターゲット化するデバイスグループが必要になります。以下は、macOS 26 以降を実行しているデバイスをターゲット化するスマートコンピュータグループです:
resource "jamfplatform_device_group" "macos_26_plus" {
name = "macOS 26+"
group_type = "smart"
device_type = "computer"
criteria = [
{
criteria = "Operating System Version"
operator = "greater than or equal"
value = "26.0"
}
]
}
このグループは、benchmark および blueprint リソース内で ID で参照でき、Terraform は依存関係グラフを理解し、すべてを正しい順序で作成します。
Compliance Benchmark
Compliance Benchmark は、Compliance Benchmark Engine に組み込まれている mSCP ベースラインを使用します。最初に、データソースを使用して必要なベースラインのルールをフェッチします。次に、そのルールを参照し、デバイスグループをターゲット化する benchmark を作成します:
data "jamfplatform_cbengine_rules" "cis_lvl1" {
baseline_id = "cis_lvl1"
}
resource "jamfplatform_cbengine_benchmark" "cis_level_1" {
title = "CIS macOS Level 1"
description = "CIS Level 1 benchmark - Managed by Terraform"
source_baseline_id = "cis_lvl1"
sources = [
for s in data.jamfplatform_cbengine_rules.cis_lvl1.sources : {
branch = s.branch
revision = s.revision
}
]
rules = [
for r in data.jamfplatform_cbengine_rules.cis_lvl1.rules : {
id = r.id
enabled = r.enabled
}
]
target_device_group = jamfplatform_device_group.macos_26_plus.id
enforcement_mode = "MONITOR"
}
これにより、CIS Level 1 benchmark がモニターモードで作成され、前に定義したスマートグループにスコープされます。ベースラインのすべてのルールが含まれ、個別のルールを選択的に無効にするか、カスタム ODV 値を設定して組織の要件と一致させることができます。たとえば、特定のルールをカスタマイズするには:
rules = [
{
id = "system_settings_time_server_configure"
enabled = true
odv_value = "ntp.example.com"
},
{
id = "system_settings_critical_update_install_enforce"
enabled = true
}
]
enforcement_mode を "MONITOR_AND_ENFORCE" に設定すると、非準拠設定が自動的に修復されます。
Compliance Benchmark Engine API は現在、benchmark の PUT または PATCH メソッドを提供していないことは注目に値します。これは、Terraform 設定の benchmark リソースへの変更により、インプレース更新ではなく、destroy-and-recreate (強制置換) が発生することを意味します。既にデプロイされており、デバイスでアクティブにレポートしている benchmark に変更を加える場合は、このことを念頭に置いてください。
ここでの実際の力は、適用したルールとカスタマイズの正確なセットをバージョン管理でき、pull request 経由で変更をレビューでき、複数のテナント全体で手作業なしで同じ benchmark を複製できることです。
Blueprint
Blueprint は複数の設定コンポーネントを単一のユニットに合成し、1 つ以上のデバイスグループにデプロイされます。各コンポーネントタイプは、Declarative Device Management (DDM) 宣言設定ドメインにマップされます。以下は、遅延と自動インストール機能を備えたソフトウェア更新設定を設定する blueprint です:
resource "jamfplatform_blueprints_blueprint" "software_update_settings" {
name = "Software Update Settings"
description = "Managed by Terraform"
deployed = true
device_groups = [jamfplatform_device_group.macos_26_plus.id]
software_update_settings = {
allow_standard_user_os_updates = true
automatic_download = "AlwaysOn"
automatic_install_os_updates = "AlwaysOn"
automatic_install_security_updates = "AlwaysOn"
deferral_major_period_days = 30
deferral_minor_period_days = 14
deferral_system_period_days = 3
notifications_enabled = true
rapid_security_response_enabled = true
rapid_security_response_rollback_enabled = false
recommended_cadence = "Newest"
}
}
以下は、パスコードポリシーを実装する blueprint です:
resource "jamfplatform_blueprints_blueprint" "passcode_policy" {
name = "Passcode Policy"
description = "Managed by Terraform"
deployed = true
device_groups = [jamfplatform_device_group.macos_26_plus.id]
passcode_policy = {
require_passcode = true
require_alphanumeric_passcode = true
minimum_length = 12
minimum_complex_characters = 1
maximum_failed_attempts = 10
maximum_inactivity_in_minutes = 5
maximum_passcode_age_in_days = 90
passcode_reuse_limit = 5
}
}
各 blueprint は device_groups 属性を介して 1 つのデバイスグループセットにマップされます。これは Platform UUID のセットを受け取ります。deployed を true に設定すると、プロバイダーに blueprint をデプロイするよう指示します (また、古い場合は再デプロイします)。false に設定するとアンデプロイされます。
software_update コンポーネントを使用して特定の OS バージョンを特定の日付で実装したり、従来の設定プロファイルペイロードの場合は legacy_payloads 属性を使用したり、プロバイダーがまだ専用コンポーネントを持っていない任意の DDM 宣言の場合は custom_declarations を使用できます。
4. 設定を適用する
他のプロバイダーで知っているのと同じコマンドがここでも適用されます:
terraform init # プロバイダーをダウンロードして初期化
terraform plan # 作成、変更、または削除される内容を確認
terraform apply # 変更を適用 (確認を求められます)
既存のテナントを管理下に置く
既に blueprint、benchmark、デバイスグループがテナントで設定されている場合、最初からやり直す必要はありません。プロバイダーのすべてのリソースは terraform import をサポートしているため、既存のリソースを再作成せずに Terraform 管理下に置くことができます。
Terraform query を使用した既存リソースの検出
Terraform 1.14+ を実行している場合、プロバイダーは list resources をサポートしており、これは Terraform から既存のインフラストラクチャを直接クエリするための機能です。これは、インポート前にテナントに何があるかを検出するのに役立ちます。
クエリファイルを作成します (例: discover.tfquery.hcl):
list "jamfplatform_blueprints_blueprint" "software_update" {
provider = jamfplatform
include_resource = true
config {
search = "software update"
}
}
list "jamfplatform_cbengine_benchmark" "cis_benchmarks" {
provider = jamfplatform
include_resource = true
config {
search = "CIS"
}
}
list "jamfplatform_device_group" "smart_computer_groups" {
provider = jamfplatform
include_resource = true
config {
filter {
selector = "deviceType"
argument = "COMPUTER"
}
filter {
join_with = "and"
selector = "groupType"
argument = "SMART"
}
}
}
次に、以下を実行します:
terraform query -generate-config-out=generated.tf
Terraform がテナントをクエリし、マッチするリソースとそれらの ID を返し、リソースブロックとインポートブロックの両方を generated.tf に生成します。blueprint と benchmark リストリソースは、名前と説明に対する大文字小文字を区別しないサブストリングマッチングの search フィルターをサポートしています。デバイスグループリストリソースは、name、description、deviceType、groupType の RSQL セレクターを持つ filter ブロックをサポートし、返されるグループを正確に制御できます。
リソースをインポートする
必要な ID を入手したら、インポートブロックを使用して管理下に置くことができます。Terraform 1.5+ の場合:
import {
to = jamfplatform_blueprints_blueprint.software_update_settings
id = "your-blueprint-uuid"
}
import {
to = jamfplatform_cbengine_benchmark.cis_level_1
id = "your-benchmark-uuid"
}
terraform plan を実行してインポートされたリソースの設定を生成し、必要に応じて調整してから、その時点からコードとして管理されます。リソースの一括インポートの詳細については、HashiCorp の bulk import documentation を参照してください。
他の Jamf プロバイダーと並んで使用する
このプロバイダーは、Jamf エコシステムの他の Terraform プロバイダーと並んで動作するように設計されています。以下を一緒に使用できます:
- Jamf Protect Provider - Jamf Protect GraphQL API を介して Jamf Protect のリソース (エンドポイントセキュリティプラン、脅威防止、テレメトリなど) を管理します。
- Deployment Theory Jamf Pro Provider - Classic および Pro API を介して Jamf Pro のリソース (ポリシー、スクリプト、設定プロファイル、グループなど) を管理します。
これらのプロバイダー間で、単一の Terraform プロジェクトからコードとしてフル Jamf 環境を管理できます。一般的なパターンは、Jamf Pro プロバイダーを使用してスマートグループやポリシーなどのリソースを作成し、その結果の Platform ID を Jamf Platform プロバイダーで benchmark と blueprint の参照として使用することです。
参加する
プロバイダーは MPL ライセンスの下でオープンソースであり、HashiCorp および OpenTofu レジストリの両方で公開されています。これは HashiCorp の Terraform Plugin Framework (Protocol v6) 上に構築されており、全体を通じて統合テストを含みます。プロバイダーは、オープンソースの jamfplatform-go-sdk を使用し、これを独自の Go プロジェクトにインポートして Jamf Platform API に対するスクリプティングとオートメーションを実行できます。
貢献を歓迎します。バグレポート、機能リクエスト、pull request すべてが高く評価されています。プロバイダーは、より多くの機能が追加される際に、Jamf Platform API と同期して成長し続けます。