05818902cd
for #21019 # Checklist for submitter If some of the following don't apply, delete the relevant line. <!-- Note that API documentation changes are now addressed by the product design team. --> - [x] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/Committing-Changes.md#changes-files) for more information. - [x] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements) - [x] Added/updated tests - [x] Manual QA for all new/changed functionality |
||
|---|---|---|
| .. | ||
| certverify | ||
| cli | ||
| cmd | ||
| cryptoutil | ||
| docs | ||
| http | ||
| log | ||
| mdm | ||
| push | ||
| service | ||
| storage | ||
| tools | ||
| LICENSE | ||
| README.md | ||
NanoMDM
The contents of this directory were copied (on January 2024) from https://github.com/fleetdm/nanomdm (the
apple-mdmbranch) which was forked from https://github.com/micromdm/nanomdm.
NanoMDM is a minimalist Apple MDM server heavily inspired by MicroMDM.
Getting started & Documentation
-
Quickstart A quick guide to get NanoMDM up and running using ngrok.
-
Operations Guide A brief overview of the various command-line switches and HTTP endpoints and APIs available to NanoMDM.
Features
- Horizontal scaling: zero/minimal local state. Persistence in storage layers. MySQL and PostgreSQL backends provided in the box.
- Multiple APNs topics: potentially multi-tenant.
- Multi-command targeting: send the same command (or pushes) to multiple enrollments without individually queuing commands.
- Migration endpoint: allow migrating MDM enrollments between storage backends or (supported) MDM servers
- Otherwise we share many features between MicroMDM and NanoMDM, such as:
- A MicroMDM-emulating HTTP webhook/callback.
- Enrollment-certificate authorization
- API-driven interaction (queuing of commands, APNs pushes, etc.)
$x not included
NanoMDM is but one component for a functioning MDM server. At a minimum you need a SCEP server and TLS termination, for example. If you've used MicroMDM before you might be interested to know what NanoMDM does not include, by way of comparison.
- SCEP.
- Spin up your own scep server. Or bring your own.
- TLS.
- You'll need to provide your own reverse proxy/load balancer that terminates TLS.
- ADE (DEP) API access.
- While ADE/DEP enrollments are supported there is no DEP API access.
- Enrollment (Profiles).
- You'll need to create and serve your own enrollment profiles to devices.
- Blueprints.
- No 'automatic' command sending upon enrollment. Entirely driven by webhook or other integrations.
- JSON command API.
- Commands are submitted in raw Plist form only. See the cmdr.py tool that helps generate raw commands
- The micro2nano project provides an API translation server between MicroMDM's JSON command API and NanoMDM's raw Plist API.
- VPP.
- Enrollment (device) APIs.
- No ability, yet, to inspect enrollment details or state.
- This is partly mitigated by the fact that both the
fileandmysqlstorage backends are "easy" to inspect and query.
Architecture Overview
NanoMDM, at its core, is a thin composable layer between HTTP handlers and a set of storage abstractions.
- The "front-end" is a set of standard Golang HTTP handlers that handle MDM and API requests. The core MDM handlers adapt the requests to the service layer. These handlers exist in the
httppackage. - The service layer is a composable interface for processing and handling MDM requests. The main NanoMDM service dispatches to the storage layer. These services exist under the
servicepackage. - The storage layer is a set of interfaces and implementations that store & retrieve MDM enrollment and command data. These exist under the
storagepackage.
You can read more about the architecture in the blog post Introducing NanoMDM.