We are going to use the MDM module in Zentral to fix some of the compliance checks. We will start by creating some configuration profiles and distribute them. We will then have a look at some other resources.
We will use the mSCP project to generate some configuration profiles, but feel free to use your own profiles if you have some that you usually like to use.
So, open the terminal and navigate to the mSCP repository.
Then launch the following command:
You might need to customize the following command!
- Replace the
800-53r5_moderate.yamlfilename with the actual value
./scripts/generate_guidance.py -p build/baselines/800-53r5_moderate.yaml
This will generate mobileconfig files in the build/800-53r5_moderate/mobileconfigs/unsigned folder in the mSCP repository.
We will now include them in the Terraform configuration manually.
We will pick some of the configuration profiles, and add them to the Terraform repository.
For example, let's use com.apple.security.firewall.mobileconfig to configure the firewall.
Copy this file to the mobileconfigs subfolder in the Terraform repository.
We now need to create a new zentral_mdm_artifact resource, link it to the MDM blueprint to put it in scope, and add a zentral_mdm_profile connected to it to load the mobileconfig.
It looks like that:
resource "zentral_mdm_artifact" "mscp-firewall" {
name = "mSCP - firewall"
type = "Profile"
channel = "Device"
platforms = ["macOS"]
}
resource "zentral_mdm_profile" "mscp-firewall-1" {
artifact_id = zentral_mdm_artifact.mscp-firewall.id
source = filebase64("${path.module}/mobileconfigs/com.apple.security.firewall.mobileconfig")
macos = true
version = 1
}This can be added to the mdm_artifacts.tf file for example.
Tip
mscp-firewall and mscp-firewall-1 are Terraform resource names. They must not change. A change of a name will lead to resource being re-created. (A moved block can be used for refactoring the code). You need to pick a naming convention and stick to it! As you probably know:
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. – Phil Karlton?
In Zentral, we keep the different versions of an attrifact, we do not change an artifact in place. This way, we know exactly which configuration is on a given device. A version can be removed once it is not present on enrolled devices anymore.
Now that we have the artifact, we need to link it to a blueprint. In the mdm_default_blueprint.tf file, add the following resource:
resource "zentral_mdm_blueprint_artifact" "mscp-firewall" {
blueprint_id = zentral_mdm_blueprint.default.id
artifact_id = zentral_mdm_artifact.mscp-firewall.id
macos = true
}Why is it a separate resource ? Because the same artifacts can be added to different blueprints. There are also other attributes available like excluded_tag_ids to change the scope of the artifact for a given blueprint.
You an now make a PR and deploy this into Zentral.
Tip
One the PR is merged, go to the MDM > Artifacts section of Zentral and look for the new artifact.
The MDM will not automatically push new artifacts to your whole fleet (it could be thousands of machines!). You can instead go to the MDM > Devices section, and open the detail view of an enrolled device. You will be able to see the currently installed artifacts. There is also a green button above the list of commands. Click on it to ping the device. After a few seconds, you should see the new artifacts reported as present on the device (reload the page if necessary.)
You can now re-run the compliance checks (Force full sync action in the inventory + Managed Software Center Check Again) and see if the firewall checks are now OK.
We have decided to keep the mobileconfig files in the repository in their original form. You can use your favorite tools to generate them. Terraform and the HCL configuration language and functions unlock really powerful possibilities.
Tip
Open the Santa configuration profile in your repo or on GitHub.
Notice that we use fqdn and secret variables. The secrets are not included in the repository!
Look now at the Terraform resource for the corresponding profile.
Notice how we use the templatefile function to load the file and to pass the variables.
Find the origin of the secret.
That's it for the mobileconfigs in Zentral. Let's move on!
FileVault could be configured with configuration profiles, but since it is a strong requirement for all organizations, and since it requires some orchestration, especially with the Private Recovery Key escrow, we have decided to simplify the process and built the management around a specific resource.
We are going to use a zentral_mdm_filevault_config resource.
So, let's add a new resource to the mdm_default_blueprint.tf file in our repository:
# FileVault
resource "zentral_mdm_filevault_config" "default" {
name = "Default"
escrow_location_display_name = "PSUMAC24 GitOps Workshop"
at_login_only = true
bypass_attempts = 0
destroy_key_on_standby = true
show_recovery_key = false
}We also need to add this to the blueprint. We need to add a filevault_config_id attribute to the existing blueprint resource to point to the new config:
resource "zentral_mdm_blueprint" "default" {
name = "Default"
collect_apps = "ALL"
collect_certificates = "ALL"
collect_profiles = "ALL"
filevault_config_id = zentral_mdm_filevault_config.default.id
}As usual, commit your changes, make a Pull Request, review the changes and merge the PR to deploy the new configuration in your instance!
Tip
In the MDM > Blueprints section, open the blueprint, and notice that it contains the new FileVault configuration.
In the MDM > Devices section, find your test device, and ping it with the green button above the list of commands. Reload the page until you see that the FileVault setup was done.
On your test device, logout and login again. It should trigger the FileVault setup.
You can now re-run the compliance checks (Force full sync action in the inventory + Managed Software Center Check Again) and see if the FileVault enabled check is now OK.
Let's configure the software updates now. Software update enforcement was introduced one year ago with macOS 14. (Last month Apple announced a new declaration to manage even more settings, but we are still working on integrating this to Zentral!).
Let's add a zentral_mdm_software_update_enforcement resource in the mdm_default_blueprint.tf file:
# Software update enforcement
resource "zentral_mdm_software_update_enforcement" "default" {
name = "Default"
platforms = ["macOS"]
max_os_version = "15"
delay_days = 7
}
Like the FileVault resource, we need to link this to the blueprint. But UNLIKE the FileVault resource, you can link multiple software update enforcement resources to the same blueprint. You can have different targets and delays, and scope the software update enforcement with machine tags.
Your blueprint resource should look like that:
resource "zentral_mdm_blueprint" "default" {
name = "Default"
collect_apps = "ALL"
collect_certificates = "ALL"
collect_profiles = "ALL"
filevault_config_id = zentral_mdm_filevault_config.default.id
recovery_password_config_id = zentral_mdm_recovery_password_config.default.id
software_update_enforcement_ids = [zentral_mdm_software_update_enforcement.default.id]
}Again, commit your changes, make a Pull Request, review the changes and merge the PR to deploy the new configuration in your instance!
Tip
In the MDM > Blueprints section, open the blueprint, and notice that it contains the new FileVault configuration.
In the MDM > Devices section, find your test device, and ping it with the green button above the list of commands. Reload the page until you see that a new DeclarativeManagement command was acknowledged.
On the device, open the MDM profile and look for the new Software Update declaration.
We have already configured an Enterprise App in your instance: the bootstrap package. Let's have a look at how we configured it, and which strategy we used to be able to load the package file.
Tip
In the mdm_artifacts.tf file, find the Enterprise App artifact resource.
Find the resource used to load the package.
Notice that the file is not included in the repository, but loaded from AWS S3.
Find the artifact in the MDM > Artifacts section in Zentral.
This is it for the Zentral MDM configuration. Let's have a look at Munki now.