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.
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.