It wont be for that year (except if someone help on the finance side).
But what we could start here is a proper RFC, to define an open protocol between NixOS and an MDM server.
I’d be interested in helping out design an MDM standard for NixOS, feel free to contact me if you’re building something.
Update: I just started working on one. Email me if you want to contribute!
2 Likes
Hi
Sorry for the lack of time recently, we are working on the Windows support for our MDM, and so learning how bad a MDM protocol can be compare to our initial support of Apple’s MDM.
Of course I’m interested to work on it, I think starting with an RFC defining protocol goals, mindset, and integration with “regular” NixOS should be the initial step.
What do you think?
My initial idea is to rely on Tailscale or Headscale as much as possible to abstract away node (machine) discovery and management, communication through different networks and CG-NAT and potentially key exchange (though I think it’d be safer to do it through the NixOS config). Kind of like cLAN uses ZeroTier (although I’ve never used it so I may be wrong about that).
Then each node has an HTTP server with an API that the server can talk to. From here the server can ask the machine’s status, tell it to update, fetch the machine’s logs etc.
Some areas to explore:
- Is relying on Tailscale or Headscale so much something we would want from this protocol ? Some people/organizations probably cannot/don’t want to adopt Tailscale. If not, how should we go around discovery and communication ?
- The server can build and copy the derivations directly to the target to avoid having each machine pull the same packages from
cache.nixos.org. It’d drastically reduce the amount of network I/O and overall CPU time needed to update a lot of machines.
I do want to make an open protocol and a free software implementation, although Bravas could absolutely implement it on their own too, or use the free software implementation and sponsor it.
If this is going somewhere, we can create a Matrix room to branch off of this thread.
1 Like
My recommendation would be to not jump on the technology first. Especially not copying something like head/tail scale which had different needs.
In the order we should define:
- what a MDM is for in NixOS
- what is the expected use in organization (description of business use case)
- what is already here
- what are the functional needs of the MDM protocol (configuring? commanding? notifying? reporting?
- which needs can be technically answered in the same ways
Etc
My goals (and Bravas goals) is to produce RFC then implementation allowing NixOS to have an open management protocol where the OS have it’s own FOSS mdmclient with standardized exchange protocols based on easy to use and implement standard (such as JSON Rest and websocket for example).
Anything that is on the client send must be FOSS, and up to the different MDM software to implement their server side the way they wants.
As you said earlier, Nix already provides everything we need to manage NixOS hosts. What we really need right now is the glue that holds everything together and allows sysadmins to manage a large amount of machines efficiently.
An organization (or an individual with a lot of computers) would need to manage tens or hundreds of machines.
Each host would have it’s own hardware config (to account for partition UUIDs and maybe different hardware), but they probably would have at least 10 different configurations (regular workstation, workstation with different needs (say a video editor’s workstation or someone that needs CUDA for some reason, accounting’s workstations, laptops, servers, router, firewall, kiosks, etc). These would be shared across hosts.
They would need to:
- Keep the machines up-to-date and free from known vulns;
- Remotely shut down or reboot machines;
- Know the status of each machine;
- Remotely control individual hosts (SSH/Rustdesk, etc);
- Aggregate logs;
- Ensure compliance with security standards;
- Manage secrets, back keys up, etc (could be dealt with by other software).
The Nix and NixOS CLIs which already does a lot of stuff.
- Configuration through the NixOS config;
- Commanding: SSH, HTTP API, etc;
- Notifying/Reporting: (I assume you mean to transmit data from the client to the server instead of the other way around): same as commanding but in reverse ?
Not sure what you mean by that.
Feel free to add onto what I’ve just said.
1 Like
Which is one of the most complex thing. That’s why design steps are hugely critical.
That kind of things goes in a documentation / RFC: why we do things and what do we take in accounts
For example: remote control of individual hosts, but everyone behind NAT and firewall, which situation are we supporting? And is it really the role of the MDM to act as a tunnel broker? Not a single MDM protocol on the market handle that feature for example.
Will it also do the inventory collection? Looking for all installed apps and version? Looking for compliance status for example? And will it be able to react and notify on a change or will it be polling only?
Maybe it does, but without writing expectation and mind mapping of existing parts that answer some of the needs, it’s easy to mess things up
Configuration: we can configure the endpoint posture but also the user setup such as e-mail account, if so are we able to support more than one user on an endpoint? And if yes, with or without an endpoint bound to a directory service?
Commands: SSH will have hard time to works due to mobility, which mean some other protocol to pass some reduced set of commands like shutdown, reboot, device wipe, lock in lost mode, etc. Which commands can we support and what is the difference on the protocol side between a command and a configuration?
Notifying: how a MDM server will notify and endpoint of a policy change to ensure “sort of real time” spread of a local passcode complexity change for example? Are we limited to client poll based mechanism? Or can we use some kind of websocket for push notification?
Reporting: are we able to react to a local change such as a status change (like version after update, or completed full disk encryption) to inform as soon as possible the server of the new situation without waiting for a polling based mechanism?
Those are the kinds of points of details needed to be in mind for everyone, being sure that the global vision is shared, to create the least demanding most effective code base for a FOSS mdmclient.
You should definitely follow Clan then, they’re working on answering a lot of these questions in working code. But in terms of Nix upstream tooling and documentation, there’s just a lot of clean-up and stabilisation work to be done, to make the existing workflows easy to find and more straighforward to use, and to converge on solutions to well-known problems such as the ones you list.
Do they have a protocol documentation somewhere? I see a lot of explanation of what they do but not how they do it. And their interaction system seems all integrated. So not sure if it would be easy to extract as an independent client usable by any management server.
Apple MDM can handle a laptop/phone serial directly from the box. And set it up the way the company wants.
I haven’t looked into Android but I’m guessing same…
When do you onboard nixos into the mdm ?
All OS vendors have a OOB experience solution where the serial number of the platform is indeed referenced in some shared discovery server such as Apple School or Business Manager, Windows Autopilot or Android ZTE.
But all of them also have a self service enrollment system where it’s basically an authenticated enrollment profile run on an already installed device.
And all of them started by this self service solution. The automated deployment came later.
I recommend doing the same. One problem at the time: first enrolling and managing, then discovering enrollment OOB
Other point to consider in the MDM Protocol design is to know if we limit on a remote command system, or going to a desired fleet state vision
For example, the documentation of full disk encryption for NixOS Full Disk Encryption - NixOS Wiki
Quite complex and endpoint dependent.
Do we wants the management server to be complex and involved in crafting such a complex payload from a MDM point of view?
Or do we accept to put intelligence in the mdmclient to receive a policy defining a desired state (all internal storage must be encrypted) and let it do the conversion locally?
That’s why I proposed to integrate with Tailscale. Or we could just stick to giving the client a URL to contact and open a websocket or something like that. Then the sysadmin can figure out firewall punching and NAT traversal how they see fit, with Tailscale, a VPN or any other solution they already have.
You can look and parse the NixOS config, or use nix-tree. The first option may be harder to implement or incomplete, the latter exposes every derivation installed by the generation and doesn’t differenciate between applications and libraries (which may or may not be a good thing).
Depends on what compliance entails, but I would assume it is possible.
Yes.
That’s tricky. There’s nothing that prevents you from having 1000 accounts on a NixOS system, but I don’t know how well that would scale, storage-wise and build-time-wise. This requires more research.
I guess we and/or the sysadmin would have the choice ?
I tried it a bit ago, but the lack of documentation is really bad. I can’t really grasp what the project is about.
I guess that enrollment would be pretty manual at first: create the NixOS host like usual, switch to the new configuration, add the client’s hardware config and public key in the config, push and switch again, etc. I don’t know how far automated NixOS provision goes, but we probably can’t automate it tooo much.
1 Like
All MDM on the market are made to be Internet exposed.
So yes, a simple websocket can be the solution. But it needed, as always, to be evaluated from different perspective.
And more than storage, how do we handle the addressing of each user context in the MDM protocol? In a secure way
For the information, all other MDM Protocol started by being mono user (including Windows) and then evolve to be multi-user.
Maybe we can reach multi user from scratch, but it require some specificity
Legacy directory services like LDAP are unlikely to be exposed over Internet nor usable in mobility.
Windows require Entra for Cloud based Directory Service, macOS require a complex Platform SSO support, iOS require Managed Apple Account, and ChromeOS require Google Cloud Identity.
Somehow, we will need to design a way to provision users and manage them from the MDM Protocol, that need to fit in a clean IDP based workflow, especially in the modern passwordless word, but only if we consider that multi user device is a actual usecase we wants to support.
Which is questionnable. Most situation nowadays are single user devices. So design documentation need to evaluate the indented usecase we work on the remove the complexity.
It’s totally fair here to say “for the first release, we consider only single user devices to allow developers to work in a managed and compliant Linux workstation”.
That’s why I recommend starting be defining the scope of work, intended use, etc.
I’m fine with that. We have already a lot to figure out, and I don’t think adding multi-user capabilities will introduce that many breaking changes.
Here is a repo where I will try to collect information we already shared
Following this method [RFC 0138] Developing RFCs in repositories by infinisil · Pull Request #138 · NixOS/rfcs · GitHub
@tasiaiso do you wants to be co-author on this?
I won’t have much free time this July for school reasons but sure, I’d love that !