GitOps: Support environment variables in configuration profiles

[getvictor]

Goal

User story
As an endpoint operator using Fleet's best practice GitOps,
I want to use an environment variable in my repo and use it to populate a configuration profile
so that I can hide the secrets I use in configuration profiles.

Context

• Product designer: @noahtalerman

The following workaround is currently used in Fleet's internal dogfood instance: https://github.com/fleetdm/fleet/blob/main/.github/workflows/dogfood-gitops.yml#L40-L45

Changes

Product

• GitOps changes: Add the ability to use environment variables in configuration profiles.
  • If an environment variable is empty, error out.
• Outdated documentation changes:
  • https://github.com/fleetdm/fleet/pull/19740/files#diff-a58faf49252a4527962a6bf925594d505997de610248a0bca6dd4bca233814fbR266
• Changes to paid features or tiers: Available in Fleet Free and Fleet Premium

Engineering

• Database schema migrations: TODO
• Load testing: TODO

ℹ️  Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

QA

Risk assessment

• Requires load testing: TODO
• Risk level: Low / High TODO
• Risk description: TODO

Manual testing steps

1. Step 1
2. Step 2
3. Step 3

Testing notes

Confirmation

1. Engineer (@____): Added comment to user story confirming successful completion of QA.
2. QA (@____): Added comment to user story confirming successful completion of QA.

[noahtalerman]

Hey @getvictor, heads up, we didn't have the space to take this one on in the current design sprint (4.48).

Leaving the feature fest label on it so we can weigh it at the next feature fest.

[noahtalerman]

Hey @getvictor, heads up, we brought this into the upcoming design sprint (4.49).

[dherder]

examples of variables we would want to support:
$SERIAL_NUMBER
$UDID
$USERNAME or $EMAIL_PREFIX (everything before the @ symbol)

It would be great if, at any time, a device variable that is used on a profile is updated, that profile will be re-installed on the device with the updated variable.

These are some of the variables that were supported by Profile Manager back in the day: https://support.apple.com/en-ca/guide/profile-manager/mdm53kqu8903/mac

[nonpunctual]

related to #16958

[getvictor]

@noahtalerman

I assume you meant environment variables and not configuration variables. fleetctl gitops does not have direct access to GitHub configuration variables (or secrets) and they must be converted to environment variables.

The syntax mentioned in #16958 would conflict with this feature because that is the standard syntax for an environment variable: $SOMETHING. Perhaps use %SOMETHING% or something else unique?

[getvictor]

There is also a corner case bug with the current env variables support, which is due to golang/go#43482: #18467

[nonpunctual]

@getvictor I don't think this has anything to do with environment variables. I think the idea is that when we deliver configuration profiles to devices, Fleet has the ability to populate variable strings in the configuration profile from values in the database before or at the time it's written to the device kind of like the way a here doc works in bash shell. Similar to this:
https://learn.jamf.com/en-US/bundle/jamf-pro-documentation-current/page/Computer_Configuration_Profiles.html#ariaid-title2

[noahtalerman]

@getvictor, I think I meant environment variables.

This story addresses the problem in which we want to pass the Chrome enrollment token from an environment variable to a profile w/o having the modify the bash script that the GitHub action runs.

Sorry for the confusion.

The syntax mentioned in #16958 would conflict with this feature because that is the standard syntax for an environment variable: $SOMETHING. Perhaps use %SOMETHING% or something else unique?

Thanks for pointing this out! Good to keep in mind when we address that problem.

I think the idea is that when we deliver configuration profiles to devices, Fleet has the ability to populate variable strings in the configuration profile from values in the database before or at the time it's written to the device kind of like the way a here doc works in bash shell.

@nonpunctual this is a separate problem tracked in a user story here: #16958

[nonpunctual]

Sory for confusion.

[getvictor]

@noahtalerman If the env var doesn't exist, should we throw an error? Currently, it just becomes blank. This is related to #18467

I suggest we throw an error for this story and for the current env var substitution we do in GitOps. This will prevent customer setting blank options, and will warn them if they are using $SOMETHING syntax without realizing that it will be substituted as env var.

[noahtalerman]

If the env var doesn't exist, should we throw an error? Currently, it just becomes blank.

@getvictor, displaying an easy to understand error message makes sense to me. Nice catch.

When you land on an error message can, you please add that to the "Changes" section in this story's description?

This way, other folks can give feedback and we know to test the error message during QA.

[marko-lisica]

TODO: docs PR #17890

[marko-lisica]

Hey @dherder & @zayhanlon, this customer request is shipped.

[noahtalerman]

Merging docs is still TODO: #19740

After the docs are merged we can close this user story.

[fleet-release]

Config profiles deep,
Seeds hidden in GitOps cloud,
Fleet's secret to keep.