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

• [x] 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

• [x] 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

• [x] Submit a CSR to https://fleetdm.com/api/v1/deliver-apple-csr?deliveryMethod=json to get a signed CSR.

  • [x] 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
  • [x] For more details about the endpoint, see https://github.com/fleetdm/fleet/issues/19027
  • [x] Be careful to handle timeouts, etc from fleetdm.com appropriately

• [x] Ensure right permissions are enforced

• [x] Respond with the signed CSR

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

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

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

Encryption

Fleet uses encryption at rest, and encryption in transit. In addition, it is necessary to encrypt sensitive data before inserting into the database. We still want to maintain a great UX, so we will handle all of this in background and not require input from the user.

• [x] Create a new required environment variable to store the MDM cert encryption key. This is only required if they want to upload their certs vs. storing them as environment variables.
• [ ] Update Terraform and Render blueprints to generate a random key and set the environment variable without input from the user. Coordinate with @rfairburn for Terraform or @edwardsb for the Render blueprint as needed.
• [x] Use the MDM cert encryption key to encrypt and decrypt any MDM certs stored in the database.
• [x] For fleetctl preview, generate a random string and store it on the file system to support multiple runs without resetting your MDM configuration.
• [ ] Update the documentation to include the new environment variable and instructions for migrating from existing environment variables for users who wonder what it is or need to set it manually in a non-best practice deployment.
• [ ] Notify any existing on-prem MDM customers before upgrading so they can manually set the encryption key environment variable.
• [x] Note: this key needs to be used to encrypt MDM certs for both Apple and Windows.

Endpoint to upload APNs certificate

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

• [x] 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

• [x] Ensure right permissions are enforced
• [x] Delete APNs and SCEP information from the database
• [x] 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.