Epic: Add support for deployment profiles

[jandubois]

Deployment profiles are installed on a machine before the software itself is installed (or maybe before first run).

The profile has the same content as our settings.json file and serves two purposes:

1. It provides the initial first-run configuration if settings.json does not yet exist. If all required settings are provided, then no first-run dialog will be shown.

2. It provides "locked" settings. Currently there is just a single lockable setting¹: the Allowed Images list. Locked settings are applied on each app start and override whatever is in settings.json. Locked settings also cannot be changed in the Preferences dialog (or via rdctl). Settings can only be locked via profile; the locked state in settings.json will always be false (because there would be no mechanism to unlock again).

Deployment profiles can be installed either at the system or the user level and must be deployable by system management software in enterprise settings (Group Policy, Apple profiles, etc). The system level profile takes precedence over a user level profile, if both exist (i.e. the user profile is ignored if the system profile exists).

Profiles should be stored in the registry (on Windows) and probably as .plist files instead of JSON on macOS.

Install locations still to be determined.

Deployment profiles are not part of the app installation and will not be removed by a Factory Reset.

Any initial configuration provided by an installer program will go into the regular settings.json file and not be stored as a profile. Locked setting from profiles will still overrule installer configurations.

There is no UI component to deployment profiles, although we may provide a tooltip on the 🔒 icon that explains that the setting has been locked by deployment profile.

Stories

• Remove kim builder #3886
• Implement settings v5 schema [2d] #3746
• Migrate settings.json v4 → v5 during upgrade [2d] #3747
• Implement new /v1 API version for version 5 settings format [5d] #3756
• Document that the v1 API is still internal and experimental #3927
• Move locked-field checking from issue 3756 to here #3862
• Update rdctl start and rdctl set to use v5 option names [1d] #3748
• Implement ReadDeploymentProfile function for Linux [2d] #3749
• Implement ReadDeploymentProfile function for Windows [5d] #3750
• Implement ReadDeploymentProfile function for macOS [1d] #3751
• Update settings.Load to support deployment profiles [2d] #3752
• Update first-run algorithm to deal with incomplete deployment profiles [1d] #3759
• Is it "imageAllowList" or "allowedImages" #3919
• Support Windows registry arrays as a REG_MULTI_SZ string #4144
• Add BATS test for deployment profiles [5d] #3753
• Document deployment profiles [2d] #3754

Acceptance Criteria

Each of the stories above should have their own acceptance criteria.

Release notes

• Make sure that deployment profiles are labelled as an experimental feature!

Footnotes

1. Another candidate for lockable settings would be installable extensions. ↩

[mook-as]

For Group Policies on Windows, it's customary to have a separate registry key per setting (not just serialized JSON) and provide group policy administrative templates to help adminstrators manage them (providing selections, etc.)

[byjrack]

Love it. We don't have a ton of configs we need to push out, but being able to use standard config management systems; Windows GPO, Microsoft Intune, JAMF Pro, etc. is super helpful. Technologists may or may not use the self-service install portals we manage and then we need to make sure we don't lag the versions offered too much. Deploying/Staging a file granted can feel much like configuring a GPO or a Config Policy, but the tools for managing them make doing that an implementation detail. The Policy is the first class object and can make creating the config much more straight foward as well as scoping is coherent to the config management system.

Deploying a config whether the product is installed or not helps to get folks going with a known good config. For us it will be things like proxy, hostforwarder, vpnkit/MTU, etc. Those are settings that when they are not enabled/configured cause the product to error out or act in unexpected ways. I know not all of those are available in settings.json today, but hopefully you get the idea.

[jandubois]

it's customary to have a separate registry key per setting

Yes, that allows you to manipulate values with standard registry tools.

How does this handle lists of values (e.g. the list of patterns in Allowed Images list)? Would this be a single REG_MULTI_SZ value (strings separated by \0), or have a numbered key for each pattern, like ...\pattern_1 etc?

Maybe we can choose, in which case the question is what works better for administrators / templates?

[byjrack]

Could look at ADMX templates to see if they would fit folks needs. That can deploy the v registry configs and then it's just the codepath in RD to read that and prioritization (hklm/policies, settings.json, etc)

[jandubois]

I think we will want to have an rdctl command that turns the current configuration into various profile formats, and maybe even auto-generate a template (we do have an OpenAPI spec for the settings). Needs more research first. 😄

[byjrack]

I would say

1. Make sure there are enough configs admins want to and can push from on high. Maybe image author and/or registry are a good place to start.
2. How to deploy the policy using common config management practices MSI, gpo, mdm, etc.
3. Creation and management of that construct. Oma-uri is a good neutral option for handling a lot of mdm stuff, but cfg mgmt gets local and opinionated really fast.