Dans nos articles précédents, nous avons couvert les fondamentaux de l'Infrastructure as Code et comment gérer la configuration de Jamf Pro et Jamf Protect avec Terraform. Si vous ne les avez pas encore lus, ils valent le coup d'être consultés car ils couvrent l'installation, la structure du projet et la gestion de l'état.
Cette fois, nous tournons notre attention vers les API Jamf Platform, qui ont récemment entré en bêta publique. Ces API alimentent une nouvelle génération de microservices Jamf qui s'exécutent aux côtés de Jamf Pro et Jamf Protect, incluant les blueprints, les Compliance Benchmarks et les groupes d'appareils. Nous avons créé un fournisseur Terraform dédié qui vous permet de gérer ces ressources en tant que code.
Pourquoi un fournisseur dédié pour les microservices Jamf Platform ?
Les API Jamf Platform constituent une surface API distincte des API Jamf Pro Classic et Pro. Elles alimentent des capacités différentes des ressources que vous gérez avec le fournisseur Jamf Pro, et elles s'authentifient via un ensemble différent de credentials auprès d'une passerelle API régionale (us.apigw.jamf.com, eu.apigw.jamf.com ou apac.apigw.jamf.com).
Les Blueprints vous permettent de définir l'état de configuration souhaité pour un groupe d'appareils et le déployer en une seule opération. Les Compliance Benchmarks vous permettent d'appliquer des lignes de base de sécurité conformes aux standards de l'industrie provenant du macOS Security Compliance Project (mSCP) et de surveiller comment votre parc se mesure. Les groupes d'appareils vous offrent un moyen d'organiser et de cibler les appareils au niveau de la plateforme. Ce sont toutes des capacités de première classe qui méritent leur propre fournisseur, avec des schémas conçus spécifiquement pour les ressources qu'ils gèrent.
Si vous avez géré les blueprints et benchmarks via la console Jamf Pro, vous savez déjà que recréer une configuration sur les tenants ou suivre les modifications au fil du temps implique beaucoup de clics. Avec ce fournisseur, l'intégralité de votre configuration réside dans Git, passe par la révision de code et s'applique de manière cohérente partout où vous en avez besoin.
Qu'est-ce que cela couvre ?
Le fournisseur est livré avec 3 ressources, 12 sources de données, 3 ressources de liste et 4 actions d'appareils. Voici les domaines clés :
Compliance Benchmark Engine - Créez et gérez les compliance benchmarks par rapport aux lignes de base mSCP, notamment CIS Level 1 et 2, NIST 800-53 (Low, Moderate, High) et DISA STIG. Vous pouvez activer ou désactiver les règles individuelles, personnaliser les valeurs définies par l'organisation (ODV) et cibler les benchmarks vers des groupes d'appareils spécifiques. Les sources de données vous permettent de interroger les lignes de base, les règles et les benchmarks existants disponibles.
Blueprints - Définissez des blueprints de configuration d'appareils couvrant l'application des mises à jour logicielles, les paramètres de mise à jour logicielle, les politiques de code d'accès, les paramètres Safari, les signets et extensions, la gestion des disques, les paramètres des accessoires audio, les paramètres mathématiques, les tâches de service en arrière-plan, les fichiers de configuration de service, les anciens payloads et les déclarations DDM personnalisées. Chaque blueprint cible un ou plusieurs groupes d'appareils et peut être déployé ou non déployé en tant que code. Les sources de données vous permettent de interroger les blueprints existants et les composants de blueprint disponibles.
Groupes d'appareils - Créez des groupes d'appareils intelligents et statiques pour les ordinateurs et les appareils mobiles, avec des règles d'adhésion basées sur des critères pour les groupes intelligents et des listes de membres explicites pour les groupes statiques. Ces groupes sont référencés par les benchmarks et les blueprints pour le ciblage.
Unified Inventory - Sources de données en lecture seule pour interroger les appareils individuels et les listes d'appareils au niveau de la plateforme.
Actions d'appareils - Actions Terraform 1.14+ pour les opérations d'effacement, de redémarrage, d'arrêt et de désattribution sur les appareils gérés.
Toutes les ressources supportent les opérations CRUD complètes et terraform import.
Mise en route
Si vous avez suivi l'article d'introduction, vous devriez déjà avoir Terraform installé et une compréhension basique de la manière dont les projets sont structurés. Les étapes ici sont similaires.
1. Créer des credentials API pour l'API Jamf Platform
Accédez à Jamf Account et créez un client API avec les autorisations dont vous avez besoin pour les ressources que vous souhaitez gérer. Le guide Getting Started sur le portail des développeurs Jamf décrit ce processus.
2. Configurer le fournisseur
Ajoutez le fournisseur à votre configuration 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
}
Vous pouvez également utiliser des variables d'environnement pour garder le bloc fournisseur propre :
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"
Comme toujours, assurez-vous que ces credentials ne finissent pas dans votre référentiel Git. Utilisez un fichier terraform.tfvars et ajoutez-le à votre .gitignore.
3. Définir vos ressources
Parcourez quelques exemples à fort impact.
Groupes d'appareils
Avant de créer des benchmarks ou des blueprints, vous voudrez un groupe d'appareils pour les cibler. Voici un groupe d'ordinateurs intelligent qui cible les appareils exécutant macOS 26 ou ultérieur :
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"
}
]
}
Ce groupe peut ensuite être référencé par ID dans vos ressources de benchmark et de blueprint, afin que Terraform comprenne le graphe de dépendances et crée tout dans le bon ordre.
Compliance benchmarks
Les compliance benchmarks utilisent les lignes de base mSCP intégrées à Compliance Benchmark Engine. D'abord, utilisez une source de données pour récupérer les règles de la ligne de base que vous souhaitez. Ensuite, créez un benchmark qui référence ces règles et cible votre groupe d'appareils :
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"
}
Cela crée un benchmark CIS Level 1 en mode surveillance, limité au groupe intelligent que nous avons défini précédemment. Chaque règle de la ligne de base est incluse, et vous pouvez désactiver sélectivement les règles individuelles ou définir des valeurs ODV personnalisées pour correspondre aux exigences de votre organisation. Par exemple, pour personnaliser une règle spécifique :
rules = [
{
id = "system_settings_time_server_configure"
enabled = true
odv_value = "ntp.example.com"
},
{
id = "system_settings_critical_update_install_enforce"
enabled = true
}
]
Définir enforcement_mode à "MONITOR_AND_ENFORCE" remédiera automatiquement aux paramètres non conformes.
Il est important de noter que l'API Compliance Benchmark Engine n'offre actuellement pas de méthode PUT ou PATCH pour les benchmarks. Cela signifie que toute modification d'une ressource de benchmark dans votre configuration Terraform entraînera une destruction et une recréation (remplacement forcé) plutôt qu'une mise à jour sur place. Gardez cela à l'esprit lorsque vous apportez des modifications aux benchmarks qui sont déjà déployés et signalent activement sur les appareils.
Le véritable pouvoir ici est que vous pouvez contrôler la version de l'ensemble exact de règles et de personnalisations que vous avez appliquées, examiner les modifications via les demandes de fusion et répliquer le même benchmark sur plusieurs tenants sans aucun effort manuel.
Blueprints
Les Blueprints composent plusieurs composants de configuration en une seule unité qui est déployée sur un ou plusieurs groupes d'appareils. Chaque type de composant correspond à un domaine de configuration Declarative Device Management (DDM). Voici un blueprint qui configure les paramètres de mise à jour logicielle avec des reports et installation automatique :
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"
}
}
Et voici un blueprint qui applique une politique de code d'accès :
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
}
}
Chaque blueprint correspond à un ensemble unique de groupes d'appareils via l'attribut device_groups, qui prend un ensemble d'UUID de plateforme. Définir deployed à true indique au fournisseur de déployer le blueprint (et de le redéployer s'il devient obsolète). Le définir à false le dédéploie.
Vous pouvez également utiliser le composant software_update pour appliquer une version OS spécifique à une date spécifique, l'attribut legacy_payloads pour les anciens payloads de profil de configuration, ou custom_declarations pour les déclarations DDM arbitraires que le fournisseur n'a pas encore de composant dédié.
4. Appliquer votre configuration
Les mêmes commandes que vous connaissez des autres fournisseurs s'appliquent ici :
terraform init # Initialize and download the provider
terraform plan # Review what will be created, changed or destroyed
terraform apply # Apply the changes (you'll be asked to confirm)
Placer un tenant existant sous gestion
Si vous avez déjà des blueprints, des benchmarks et des groupes d'appareils configurés dans votre tenant, vous n'avez pas besoin de recommencer de zéro. Chaque ressource du fournisseur supporte terraform import, afin que vous puissiez placer les ressources existantes sous gestion Terraform sans les recréer.
Découvrir les ressources existantes avec Terraform query
Si vous exécutez Terraform 1.14+, le fournisseur supporte les ressources de liste, une fonctionnalité qui vous permet de interroger votre infrastructure existante directement à partir de Terraform. C'est utile pour découvrir ce qui existe déjà dans votre tenant avant de l'importer.
Créez un fichier de requête (par exemple 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"
}
}
}
Ensuite, exécutez :
terraform query -generate-config-out=generated.tf
Terraform interrogera votre tenant, renverra les ressources correspondantes ainsi que leurs ID, et générera à la fois les blocs de ressources et les blocs d'importation dans generated.tf. Les ressources de liste blueprint et benchmark supportent un filtre search pour la correspondance de sous-chaîne insensible à la casse par rapport aux noms et descriptions. La ressource de liste de groupe d'appareils supporte les blocs filter avec des sélecteurs RSQL pour name, description, deviceType et groupType, vous donnant un contrôle précis sur les groupes retournés.
Importer des ressources
Une fois que vous avez les ID dont vous avez besoin, vous pouvez utiliser les blocs d'importation pour placer les ressources sous gestion. Avec 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"
}
Exécutez terraform plan pour générer la configuration pour les ressources importées, affinez-la selon vos besoins, et à partir de ce moment, elles sont gérées en tant que code. Pour plus d'informations sur l'importation en masse de ressources, consultez la documentation sur l'importation en masse de HashiCorp.
Utilisation avec d'autres fournisseurs Jamf
Ce fournisseur est conçu pour fonctionner avec les autres fournisseurs Terraform de l'écosystème Jamf. Vous pouvez l'utiliser avec :
- Jamf Protect Provider - pour gérer les ressources dans Jamf Protect (plans de sécurité des endpoints, prévention des menaces, télémétrie et plus) via l'API GraphQL de Jamf Protect.
- Deployment Theory Jamf Pro Provider - pour gérer les ressources dans Jamf Pro (politiques, scripts, profils de configuration, groupes et plus) via ses API Classic et Pro.
Entre ces fournisseurs, vous pouvez gérer votre environnement Jamf complet en tant que code à partir d'un seul projet Terraform. Un modèle courant consiste à utiliser le fournisseur Jamf Pro pour créer des ressources comme les groupes intelligents et les politiques, puis référencer les ID de plateforme résultants dans le fournisseur Jamf Platform pour les benchmarks et les blueprints.
Participer
Le fournisseur est open-source sous la licence MPL et publié sur les registres HashiCorp et OpenTofu. Il est construit sur le Terraform Plugin Framework de HashiCorp (Protocol v6) et comprend des tests d'intégration tout au long. Le fournisseur utilise le jamfplatform-go-sdk open source que vous pouvez importer dans vos propres projets Go pour les scripts et l'automatisation contre l'API Jamf Platform.
Nous accueillons les contributions. Les rapports de bugs, les demandes de fonctionnalités et les demandes de fusion sont tous appréciés. Le fournisseur continuera à croître en parallèle avec les API Jamf Platform à mesure que de nouvelles capacités sont ajoutées.