Have you guys considered making it possible to restrict the provisioning of new devices?
Specifically I was thinking an IP address based restriction, or requiring a key to be available.
This is a tie in to our secure boot work where we would love to be able to restrict provisioning to the IP address of the factory, or require a key (which could be provided via USB for example).
Once provisioned of course the device key is all that is required. No changes there.
Hey,
I am not aware of any ideas/plans to do this; but it’s an interesting idea. I am wondering if it’s possible for you to build a custom balenaOS image which has an encrypted config.json blob and an agent to decrypt it on startup using a remote service. This way your provisioning routing would be:
config.txt (the same on all devices)This way you could control which IPs could decrypt the blob.
Or… thinking more about it. You can actually register an device out-of-band via the balena CLI tools - then build a config.json for that device specifically and inject it in the warehouse/factory.
Also, small typo above, I meant config.json all along - config.txt is something different 
Option 1. isn’t a bad idea, although it still involves exporting a key we (fleet operator) can’t change or manage. Since the device needs that key for provisioning, it has be able to decrypt it.
Also putting on my (unlikely) dedicated bad actor hat this is a potential exploitable behavior. For example if I wanted to mess with a company I’m betting firing off constant device provisioning requests (each costing the fleet operator $1+) would be very annoying to deal with.
This could possibly be extended by having resin supervisor clear the provisioning key in config.json when writing the device id and related post provisioning fields. Thoughts? Is this the only time the balena API key is used?
Option 2.
Nice idea, simpler than option 1 (basically I’d have the flasher do the provisioning). Like option 1 is this the only time the balena API key for the application used?
Bump
Hi,
Yes the provisioning key that is embedded into an OS image when you download it from the dashboard is only used once to register a new device in that application. So if you change your provisioning process to have the cli register a device and inject the config.json with the appropriate device api key, that should work fine.
@afitzek thanks for that confirmation. Out of band provisioning (via the flasher) sounds like the best (and easiest) implementation.
Just finishing the second scope of works now, I’ll have a shot at this in the third probably next week.