Jamf-Concepts
Secure API access
Would really like to see functionality added for secure API access. I realize ideally this would come in the form of the Jamf binary being able to generate device specific api client credentials "on the fly" to be used by JSM or whatever (or just allow the jamf binary to update arbirary EAs via a binary command). However, alternatively, they could be encrypted using the same method some others use: which is to generate API client and secret keys, and a key pair (just sha512 or whatever). The public key would be used to do the encryption of the credentials, and the private key would get copied to the JSM computer. The credentials would then be in the config profile in an encrypted state.
JSM then can use that private key to decrypt the credentials, and delete things after the run.
Options once this is implemented would be anything from dynamically grabbing buildings/departments from Jamf, to being able to populate EAs via an API call.
Just a thought. But with more and more effort being put toward the Jamf API, it sure would be nice to leverage it. =) This would also bring it into parity with old school DEPNotify where the driving script could do anything.
I am not shooting this idea down, but I do have to point out that even with encryption, you are merely obscuring the credentials, not protecting them.
Whoever manages Setup Manager needs to encode or encrypt the credentials and Setup Manager needs to decode/decrypt them. There are two ways to provide the secret (public/private key or a passcode) to Setup Manager: through the config profile or through a prestage pkg that is installs the key somewhere in the filesystem. Either way is readable by anyone on the device if they know where to look.
You can secure the credentials and/or secret further, by making Setup Manager delete them after reading. Since Setup Manager kicks in right after enrollment, the chance that a malicious attacker has access to the system at this point is low (but not impossible). At this point, you might wonder why you need to encode/encrypt the credentials in the first place?
This is something we are actively exploring.
Thanks @scriptingosx ! Yeah, I understand it's just obfuscation at the core... it's just more obfuscation. lol. I have to admit, I'm not sure if you can use DDM and SIP to put the private key into somewhere inaccessible. Or at the very least throw the private key into a root owned, readable directory so at least it's harder to grab.
I suppose in the meantime setting EAs could be done via a helper policy that runs a script, etc.
Thanks for taking the time and energy to explore this. It's really the thing that's kept us using DEPNotify all these years... short of making a custom setup with swiftDialog (maybe using SYM as a starting point), there aren't really any other options. =/
Thanks again!
The ManagedApp framework should enable safe delivery of secrets, but so far, that is iOS/iPadOS/visionOS, and not (yet?) on macOS.
As you said, you can trigger custom policy scripts from Setup Manager which can run anything you want and deal with the credentials in a way that you find appropriate for your security needs. You can even launch SwiftDialog from those policy scripts over Setup Manager.