Nanofleet brainstorming

[bsoudan]

This project would be a new optional layer to the Nano suite oriented around managing sets of devices. This could be baked into an existing project, but the current Nano architecture is very component-ized, so proposing this as a new optional layer. @jessepeterson also mentioned future plans for Micromdm v2, maybe this belongs there?

Features:

• Subscribe to nanomdm/kmfddm updates to track managed enrollments and the current interesting state of each enrollment. Store this in an sql storage layer to support complex queries.
• Provide an API and storage layer to track arbitrary tag/value pairs for enrollments. Admins could define whatever tags are useful to them for manage/group enrollments.
  • Each enrollment can have an arbitrary set of tags. Each tag is associated with a value for that particular enrollment.
  • ex.
    • laptop-device-1 enrollment: tags tz=eastern, instance=prod, user=joe
    • laptop-device-2 enrollment: tags tz=central, instance=prod (no user tag, not associated with a user)
  • Use case examples:
    • Record region or grouping information
    • Support ACL features, such as a ‘vip’ tag for an enrollment that requires the ‘can affect vip enrollments’ ACL.
  • Set tag/value for enrollment
  • Remove tag from enrollment
  • Get all tags & values for enrollment
• Provide a way to sync these tags down to ddm properties so that they could be used for activation predicates on the device as well.
• Provide an API and storage layer to manage campaigns, sets of MDM/DDM actions that need to be applied across a set of devices
  • The campaign feature would likely drive nanocmd.
  • Start Campaign for selected enrollments
    • all est enrollments: nanofleet.tag.tz=eastern
    • all est device enrollments: nanofleet.tag.tz=eastern, nanomdm.enrollment-type=device
    • all tahoe macs: nanomdm.enrollment-type=device, kmfddm.statusitem.device.model=mac,kmfddm.statusitem.device.os.version=26
    • all enrollments that ran a previous campaign: nanofleet.campaignid=cert-renew-20251201
    • implement the same query language used for ddm activation predicates?
  • Get Campaign Status
  • Cancel Campaign
• fleetctl command line utility to manage campaigns.
• http enrollment controller?

[bsoudan]

@jessepeterson: During today's meeting, we had talked about using tags for other entities in the nano stack. Rather than only supporting tags in the nanofleet component, we could consider adding tagging APIs to the the individual nano projects, and then publish that tag information up to nanofleet just like any other interesting state the components would publish. This would provide a tagging feature across the entire nano family, even for entities other than enrollments, which may be generally useful for other things besides campaign management and ddm predicates?

[bsoudan]

We also talked about generating ddm declarations as well, because the nanofleet layer would have the most information about each enrollment. Kory was concerned this would get complicated, maybe needing to implement a custom DSL, but I was thinking something more straightforward, like a 'server predicate' that worked just like the device ddm predicates, and then a template feature which could be used to generate the final version of the profile. Probably using golang's template module (https://pkg.go.dev/text/template) but there are plenty of others out there depending on our needs.

Sample templated declaration with a server-side predicate (pretend this is json, and we're using go's template library):

type: com.apple.security.firewall

# only push this declaration to prod devices
nano.server-predicate: @status(enrollment.tag.tier) == "prod"

payload:
   enable_firewall: true
   # but then only enable logging for devices on the east coast
   {{if .enrollment.tag.tz == "eastern"}}
   enable_logging: true
   {{end}}

For a new enrollment, or the value of a tag changes, the server would scan through all the loaded declarations and evaluate the server predicate for each enrollment. If the server predicate evaluates as true, it would then generate the final declaration using the template engine, and push it down to the device. If the server predicate evaluates as false, but the declaration was already pushed to the device previously (i.e. in this instance, someone changed the tier tag from prod to dev), the server would remove the declaration from the device.

If we don't want to add extra nano-specific keys to the declaration (the server-predicate, nano would obviously remove these before sending to the device), we could just wrap the regular ddm declaration in another layer and have the nano specific stuff at the top level, i.e.

# only push this declaration to prod devices
server-predicate: @status(enrollment.tag.tier) == "prod"

declaration:
   # apple ddm declaration here

But I typically dislike nesting so I'd probably vote for the former.

[bsoudan]

Some more notes from my conversation with @jessepeterson today:

• Rather than setting up a complicated publish/subscribe mechanism to keep the nanofleet database in sync with the other nano project databases, it's reasonable to make the requirement for nanofleet that the subprojects must all use the same sql database.
• We discussed if this functionality could be a part of the nanohub project rather than a separate project, but Jesse wants to scope nanohub to only dealing with MDM/DDM, whereas the nanofleet functionality may grow over time to include other layers like ADE/DEP..
• I'm going to draw up an architecture diagram.

[bsoudan]

[bsoudan]

Today's notes from the MicroMDM community office hours meeting:

• For the fleetctl query spec, using the Apple DDM predicate language wasn't a popular idea. We discussed GraphQL instead. Though, there's no reason we can't support multiple query languages if we wanted to get really crazy.
• For the SQL storage layer, initially, we'll do something simple where we just configure each of the individual projects to use their SQL storage layers, and then nanofleet will have a simple direct SQL storage layer with intimate knowledge of the other project's SQL schema.
  • Another option would be to implement some sort of plugin interface for the storage API in each component, and then have a shared storage plugin that is configured across all 4 projects.
• Eventually, as part of MicroMDM v2 for instance, we would build all these components into a single binary and they would use the same storage layer interface. No plugin necessary since they're all running in the same process.
• For the shared storage layer interface, plugin or no, @jessepeterson is leaning towards using the Go ENT framework, which gets us benefits like automatic schema management.