Certs: API Changes for APNs and SCEP

[georgekarrv]

Endpoint to enable MDM

Per https://github.com/fleetdm/fleet/pull/18979, define an endpoint GET /api/v1/fleet/mdm/apple/request_csr

• [ ] Generate a SCEP keypair and store the raw values in the database. Encryption will be handled by another ticket. You can use the function defined here: https://github.com/fleetdm/fleet/blob/ae24e6e698a27bf39a7cc27a174e9a5cd92709a4/server/mdm/apple/cert.go#L32

• [ ] Generate an APNs key and store it in the database. Encryption will be handled by another ticket. You can use the function defined here: https://github.com/fleetdm/fleet/blob/ae24e6e698a27bf39a7cc27a174e9a5cd92709a4/server/mdm/apple/cert.go#L121

• [ ] Submit a CSR to https://fleetdm.com/api/v1/download-apple-csr to get a signed CSR.

  • [ ] The endpoint doesn't exist in fleetdm.com yet, so you can start your Fleet server setting TEST_FLEETDM_API_URL to an URL of your choice. Use a mock for the integration tests
  • [ ] For more details about the endpoint, see https://github.com/fleetdm/fleet/issues/19027
  • [ ] Be careful to handle timeouts, etc from fleetdm.com appropriately

• [ ] Ensure right permissions are enforced

• [ ] Respond with the signed CSR

• [ ] Only generate and store the following on the first time this endpoint is hit:

  • [ ] APNs Key
  • [ ] SCEP key
  • [ ] SCEP certificate

• [ ] Each time the endpoint is hit, generate a new CSR using the APNs private key stored in the database.

Endpoint to upload APNs certificate

Per https://github.com/fleetdm/fleet/pull/18979, define an endpoint POST /api/v1/fleet/mdm/apple/apns_certificate

• [ ] Store the certificate in the same table as the APNs private key

Endpoint to disable MDM

Per https://github.com/fleetdm/fleet/pull/18979, define an endpoint DELETE /api/v1/fleet/mdm/apple/apns_certificate

• [ ] Ensure right permissions are enforced
• [ ] Delete APNs and SCEP information from the database
• [ ] Do soft delete of certificates

[georgekarrv]

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

[roperzh]

I split this into a two issues, one for ABM and other for APNs/SCEP.

Adjusting the estimate accordingly.

The other issue is at https://github.com/fleetdm/fleet/issues/19179

[lukeheath]

@noahtalerman - @roperzh and I had a call and agreed on a technical solution that does not add infrastructure or require user interaction on the initial setup. Please see the "Encryption" section above for our steps. This additional work increased this issue's estimate from 5 > to 8. Please let me know if you have any questions or concerns.

[noahtalerman]

For fleetctl preview generate a random string and store in memory or store in local file system if we need to support multiple runs. @roperzh will sync with product design to determine.

@roperzh by "support multiple" runs do you mean support this workflow?

• User runs fleetctl preview and starts using Fleet. Turns on MDM features. Adds some profiles
• User stops fleetctl preview
• User starts up fleetctl preview. MDM is still turned on and the profiles are still there

If that's right, then the answer is yes. The endpoint ops team is drafting improvements to fleetctl preview to make it a 14 day trial: #18869

[noahtalerman]

Create new required environment variable to store MDM cert encryption key. This is only required if they want to upload their certs vs. storing them as environment variables.

@lukeheath why support both scenarios? Other than for backwards compatibility.

I think we want to move towards a world in which there's one, best practice way to turn on MDM in Fleet. Upload in the UI. That's what all our competitors do.

My thinking is that this will be less to maintain in the long run. Less to explain to users. Less docs. Less code.

As part of this story we could remove docs for storying certs as env variables. Keep them around in the code for backwards compatibility.

[lukeheath]

@noahtalerman

by "support multiple" runs do you mean support this workflow?

Yes, that's what we mean. That is no problem. We can store the key in the filesystem to persist between runs. (cc @roperzh)

why support both scenarios? Other than for backwards compatibility.

Purely for backward compatibility and ease of migration.

We should remove the documentation of the old MDM certificate environment variables. We should document the existence of the encryption key environment variable, even though most users won't need to set it manually. The only users who would need to know about it and set it manually are:

1. Existing MDM users that are self-hosted.
2. Anyone deploying Fleet outside our two best practice examples (Render or Terraform on AWS).

We could consider ways of removing the manual steps for these cases if we want to, but I think the number of users is small enough that it wouldn't be a good use of time, given that we already provide two best practice deployment examples.

[lukeheath]

@roperzh @jahzielv @georgekarrv I've updated the specs to reflect the latest decision.

[fleet-release]

Keypairs in place, Fleet's secure, encrypting grace, Silent cloud embrace.