Update the `GET /hosts/{id}` endpoint and `GET /device/{token}/desktop` to provide new `mdm.disk_encryption` property

[lukeheath]

Tasks

• Add new mdm.macos_settings property

{
    "mdm": {
        "enrollment_status": "enrolled",
        "server_url": "https://example.com/",
        "macos_settings": {
            "disk_encryption": "applied | action_required | enforcing | failed | removing_enforcement",
            "action_required": "log_out | rotate_key"
        }
    }
}

Note: In the specs below, a "FileVault profile" means a profile with identifier com.fleetdm.fleet.mdm.filevault in the hosts_mdm_apple_profiles table

• [x] disk_encryption values:

  • [x] applied if a FileVault profile has been successfully installed on the host AND we have fetched and are able to decrypt the key (host_disk_encryption_keys.decryptable = 1)
  • [x] action_required if a FileVault profile has been successfully installed on the host but either we didn't get an encryption key (no matching row in host_disk_encryption_keys.decryptable) or we're not able to decrypt the key we've got (host_disk_encryption_keys.decryptable = 0)
  • [x] enforcing if a FileVault profile is pending to be installed or is installed and the matching row in host_disk_encryption_keys has a field decryptable = NULL
  • [x] failed if a FileVault profile failed to be installed or removed
  • [x] removing_enforcement if a FileVault profile is pending to be removed

• [x] action_required values:

  • [x] log_out if the FileVault profile is installed but we don't have a matching row in host_disk_encryption_keys yet
  • [x] rotate_key if the FileVault profile is installed but host_disk_encryption_keys.decryptable = 0

[lukeheath]

Hey team! Please add your planning poker estimate with Zenhub @gillespi314 @mna @roperzh

[jacobshandling]

@lukeheath @noahtalerman

• Is this issue de-prioritized this sprint? If so, I assume that means the front end portion of it that uses the API is as well?

[lukeheath]

@jacobshandling This one is still in the sprint, as we're hoping to still finish it depending on how long the Okta integration takes. We did defer the Filevault Aggregates story.

[lukeheath]

@roperzh Specs look good, thanks!

[mna]

@roperzh @lukeheath Regarding the decryptable field, there's a period of time where the row in host_disk_encryption_keys exists but decryptable is null (we test for "decryptability" in a cron job at regular intervals). What should be the status in this case if the filevault profile is applied, but decriptable is still null?

The specs cover the case where we know it is decryptable (then it will be reported as "applied"), and where we know it is not decryptable (reported as "action_required"). What about when we don't know yet? Should we report it as "enforcing", as if the profile hadn't been applied on the host yet? I think that's the one that makes the most sense, short of adding another status?

[mna]

@roperzh @lukeheath sorry for the multi-ping, I think there's another possible case that's not covered: "removing_enforcement" is reported when the filevault profile is pending removal, but what about when removal is in "failed" state? Should we reuse the "failed" encryption status for that too (currently we say it is reported when the installation failed).

And then of course there's the case where there's no filevault profile (either because there never was one, or because removal was fully applied), in which case I assume we return an empty string (or should we omit the keys altogether?).

[roperzh]

@mna

Regarding the decryptable field, there's a period of time where the row in host_disk_encryption_keys exists but decryptable is null (we test for "decryptability" in a cron job at regular intervals). What should be the status in this case if the filevault profile is applied, but decriptable is still null?

I was thinking that while not technically correct, it might be OK to keep it as "action_required", my assumption being that asking the user to log out/turn off the computer is an action that will take significant time to be completed, so the IT admin wouldn't care about that extra hour, and in general might never notice unless is paying special attention to an specific device.

Having said that, "enforcing" also makes sense to me, my personal vote is for you to choose whatever you think makes most sense and we can adjust later if needed.

sorry for the multi-ping, I think there's another possible case that's not covered: "removing_enforcement" is reported when the filevault profile is pending removal, but what about when removal is in "failed" state? Should we reuse the "failed" encryption status for that too (currently we say it is reported when the installation failed).

that's what we have been doing in general for profiles, so my vote is to do the same here

And then of course there's the case where there's no filevault profile (either because there never was one, or because removal was fully applied), in which case I assume we return an empty string (or should we omit the keys altogether?).

ahhh, that's a great question, I think @lukeheath this one is for you as the API DRI

[mna]

@roperzh thanks for the clarifications!

I was thinking that while not technically correct, it might be OK to keep it as "action_required", my assumption being that asking the user to log out/turn off the computer is an action that will take significant time to be completed

My concern here is that we'd ask to user to execute a task that might not be required, and a different action might even be required once we know the status of "decryptability"? E.g. say that while that info is null we tell the user to "log_out", but once we test the key it is actually not decryptable, then they need to rotate the key. If we waited for the actual status, we may have no action to ask to the user, or we may ask them only to rotate the key.

In light of that, I'd go with keeping "enforcing" until we know the decryptability status, but of course I'm happy to reconsider if it turns out a bad choice.

that's what we have been doing in general for profiles, so my vote is to do the same here

Sounds good!

I'll update the specs with those decisions.

[roperzh]

@mna

My concern here is that we'd ask to user to execute a task that might not be required, and a different action might even be required once we know the status of "decryptability"? E.g. say that while that info is null we tell the user to "log_out", but once we test the key it is actually not decryptable, then they need to rotate the key. If we waited for the actual status, we may have no action to ask to the user, or we may ask them only to rotate the key.

great point, I didn't think of that. SGTM!

I'll update the specs with those decisions.

thank you!!

[mna]

@lukeheath There's just this question left:

there's the case where there's no filevault profile (either because there never was one, or because removal was fully applied), in which case I assume we return an empty string (or should we omit the keys altogether?)

For now, how it's implemented is that if there's no MDM configured, the mdm.macos_settings is not returned at all. If MDM is configured, it is returned and disk_encryption and action_required are set to empty strings when there is no filevault profile.

[lukeheath]

@mna If MDM is not configured, I think it's okay to omit the mdm.macos_settings object. If it is configured, but no FileVault profile is found, please set the value to null.

[mna]

@lukeheath you mean set mdm.macos_settings to null? Or each sub-field (disk_encryption and action_required)? Due to how Go's JSON encoding works, it's not simple to set macos_settings to null when mdm is configure but absent when it's not. What I can do easily is not return mdm.macos_settings at all when the file vault profile is not present.

Another option that isn't too complex is to have mdm.macos_settings present but its sub-keys set to explicit NULL (or completely absent) if file vault profile is not present but mdm is configured.

In other words, for when MDM is configured, this is hard:

• {"mdm": {"macos_settings": null}}

This is easy and not a big change (same as for when MDM is not configured):

• {"mdm": {}}

Those are also easy and not a big change:

• {"mdm": {"macos_settings": {}}}
• {"mdm": {"macos_settings": {"disk_encryption": null, "action_required": null}}}

And this is what it currently does:

• {"mdm": {"macos_settings": {"disk_encryption": "", "action_required": ""}}}

[lukeheath]

@mna I am thinking this one if MDM is configured, but the host has no profile:

{"mdm": {"macos_settings": {"disk_encryption": null, "action_required": null}}}

If MDM is not configured, I'd like to omit macos_settings entirely. Let me know if that presents any challenges.

[mna]

@lukeheath Sounds good, yeah that's a simple option.

[fleet-release]

Disk encryption blooms, Safeguards, with care applied, Fleet's cloud city thrives.