Add API endpoints to support bootstrap package

[lukeheath]

Tasks

1

• [x] Update GET global and team config endpoints to return new mdm.macos_setup property.

  "mdm": {
    "apple_bm_default_team": "💻 Workstations",
    "apple_bm_terms_expired": false,
    "enabled_and_configured": true,
    "macos_updates": {
      "minimum_version": "",
      "deadline": ""
    },
    "macos_settings": {
      "custom_settings": null,
      "enable_disk_encryption": false
    },
   "macos_setup": {
      "bootstrap_package_configured": true
   }
  },

2

• [x] Add a metadata API endpoint to retrieve package name and token.
• GET /api/_version_/fleet/mdm/apple/bootstrap/{team_id:[0-9]+}/metadata

3

• [x] Add API endpoint for both "No team" and specific teams to upload their bootstrap package.
• POST /mdm/apple/bootstrap
• Presumably, we'll use the same method to upload profiles that we used at POST /mdm/apple/profiles.
• We should look into and discuss any drawbacks of storing binaries as blobs in the database. We won't have control of the size of this file.
• Requires a token query parameter provided by the /metadata endpoint.

4

• [x] Add API endpoint for both "No team" and specific teams to delete their bootstrap package.
• DELETE /mdm/apple/bootstrap

5

• [x] Add API endpoint for both "No team" and specific teams to retrieve aggregate count of bootstrap installs.
• GET /mdm/apple/bootstrap/summary

6

• [x] Update /hosts, /labels, and /hosts/count endpoints to support the new bootstrap filter.
• Possible values: installed, pending, failed

7

• [x] Update API endpoints for host details and my device pages to provide new mdm.macos_setup property.
• GET /hosts/{host_id}
• GET /device/{device_id}

{
   "mdm": {
      "macos_setup": {
          "bootstrap_package_status": "failed",
          "detail": "MCMDMErrorDomain (12021): “InstallEnterpriseApplication" is not a valid request type."
      }
   }
}

[lukeheath]

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

[gillespi314]

@ghernandez345 @noahtalerman

FYI, we're using "detail" instead of "details" for the config profile status so I'm planning to follow the same pattern and use "detail" for the macos_setup object being returned by the API per task 7 above (it was originally spec'd as "details" in the bootstrap story).

[ghernandez345]

@gillespi314 qq or you. there is a UI state where I have to check if Apple Business Manager has been connected to the Fleet instance. It's not clear to me if there is anything on the global or team config API to determine this. Is this something that should be added so we can render this UI state correctly?

[ghernandez345]

@gillespi314 I'm thinking there is currently two ways to check if a bootstrap package has been uploaded.

1. when doing a GET /config or GET /teams/:id looking at mdm.macos_setup. bootstrap_package_configured attribute (btw I'm not seeing this attribute in the branch for this PR https://github.com/fleetdm/fleet/pull/11156, can we add that attribute.)
2. doing a call to GET /bootstrap/:team_id/metadata and seeing if we get back success response with data.

I'm thinking of checking with the first option. Wanted to see if you thought there was a preferred method of checking?

[gillespi314]

1. when doing a GET /config or GET /teams/:id looking at mdm.macos_setup. bootstrap_package_configured attribute (btw I'm not seeing this attribute in the branch for this PR add an endpoint to get an aggregate summary of bootstrap packages #11156, can we add that attribute.)

@mna, following up on @ghernandez345's request above and in our internal slack thread, are you planning to include option 1 in your other macos_setup PR or should I include this in #10935?

[mna]

@gillespi314 @ghernandez345 You mean for macos setup assistant? I hadn't thought about that yet, but looks like it'd need something like that too. If it's for the bootstrap package, if you don't mind I'd let you add it in your PR, as I'm not up-to-date on bootstrap-specific things.

[gillespi314]

@mna, thanks! I'll plan to add in bootstrap_package_configured to the general config and team config responses

[gillespi314]

@gillespi314 qq or you. there is a UI state where I have to check if Apple Business Manager has been connected to the Fleet instance. It's not clear to me if there is anything on the global or team config API to determine this. Is this something that should be added so we can render this UI state correctly?

Hmm, I'm not sure if there is anything spec'd for this.

@noahtalerman, do you know the answer?

cc @mna

[ghernandez345]

Hmm, I'm not sure if there is anything spec'd for this.

@gillespi314 I mentioned it the other day in this slack thread and @mna mentioned that I could do a request GET /api/latest/fleet/mdm/apple_bm and seeing if I get a successful response back but I think it would make sense to add this as a key on the response from the global config response. Could we add that?

[ghernandez345]

@gillespi314 can we return a created_at or uploaded_at attribute on the response to GET /api/v1/fleet/mdm/apple/bootstrap/:team_id/metadata. We need to render Uploaded at ... info and the API currently doesn't send information about when it was uploaded.

[mna]

@ghernandez345 @gillespi314 Following our discussion in the estimation meeting, @noahtalerman and @georgekarrv have opted for the field name apple_bm_configured_and_enabled to be added to the appconfig under the "mdm" key (same location as the existing enabled_and_configured.

I'll add a new task to the ticket to add that field.

[gillespi314]

@mna do you think that enabled is accurate for this though since there is a chance that the license may have expired? Also, I think we use enabled generally in the app to mean that the user has toggled an option, whereas configured implies that settings have been supplied.

Would it make sense to open a new ticket to cover this change?

[mna]

@gillespi314 Good question and good point, I think it is still enabled, but may be expired if that makes sense? You may want to discuss it more broadly on slack on this thread, though, as Noah was wondering if folks had thoughts about that name: https://fleetdm.slack.com/archives/C03C41L5YEL/p1681923412095029

Re: new ticket, sure thing, I'll create one.

[mna]

@gillespi314 @ghernandez345 https://github.com/fleetdm/fleet/issues/11246

[ghernandez345]

@gillespi314 the response for the package metadata call does not match what is in the API docs for GET /api/v1/fleet/mdm/apple/bootstrap/:team_id/metadata

the expected response is

{
  "name": "bootstrap-package.pkg",
  "team_id": 0,
  "sha256": "6bebb4433322fd52837de9e4787de534b4089ac645b0692dfb74d000438da4a3",
  "token": "AA598E2A-7952-46E3-B89D-526D45F7E233"
}

but the actual response is:

{
    "metadata": {
        "name": "Firefox 72.0.2.pkg",
        "team_id": 1,
        "bytes": null,
        "sha256": "cTFOt+aqLT1Zlrgu58MbJEUznry35cnrVyx+yEClpy4=",
        "token": "eefc51f0-7ab8-441a-a8bb-bf79ed174748"
    }
}

can we remove the wrapping metadata object and add bytes to the docs

[roperzh]

@ghernandez345 I pushed a quick fix to the PR to unblock you, the response is now:

{
  "name": "test.pkg",
  "team_id": 0,
  "sha256": "6bebb4433322fd52837de9e4787de534b4089ac645b0692dfb74d000438da4a3",
  "token": "AA598E2A-7952-46E3-B89D-526D45F7E233",
  "created_at": "2023-04-20T13:02:05Z"
}

The response now:

• Doesn't contain a bytes key at all, it doesn't make sense in the metadata response
• Is no wrapped by a metadata object anymore
• Includes only created_at (since bootstrap packages can't be updated for now)

[ghernandez345]

@roperzh @gillespi314 small nit here but the response from GET /bootstrap/summary returned failing instead of failed. Can we change it so the key name is failed? It would make it slightly easier to work with on the client but more for consistency as the value I have to send back to the API to filter hosts is failed, and its also displayed in the UI as failed.

I can make the change in my branch if needed

[gillespi314]

@ghernandez345 this should be fixed on the PR now

[gillespi314]

@roperzh, after reviewing @mna's PR for the macos setup assistant UX, I think there are some edge cases that were not considered when the bootstrap package UX was spec'd for the CLI:

Some behaviors that I see in Martin's PR that may be missing or inconsistent in the bootstrap package CRUD:

• What is the expected result if bootstrap_package: "" or bootstrap_package: null` is included in the yml config applied via fleetctl or via the API? Should that remove the existing package?

• The bootstrap package upload flow was designed to rely heavily on the fleetctl client. What happens when user accesses the config endpoints to apply yaml that contains the mdm properties but doesn't use fleetctl? How would we know?

• It looks like the team bootstrap package url is not being saved to the team config. The bytes are being uploaded and saved correctly under the team id in the mdm_apple_bootstrap_packages table, but the team config json in the datastore teams table isn't recording the url. We solved this problem for the global config, but it looks like there is something else needed for team config.

• What should happen to the team bootstrap package when a team is deleted?

[fleet-release]

Bootstrap package soars, Endpoints bring harmony, Glass city secured.