Hey there!
I’m currently using Hashicorp’s Vault to manage secrets for my Resin devices. While it’s pretty solid, I would love it if it were baked into Resin instead of having another component to manage. Docker just announced a feature for managing secrets… Is that something you see Resin doing in the future?
Interesting idea 
, just looking at the announcement (Introducing Docker Secrets Management) now. It seems that their main use case is protecting the secret in a datacenter setting, and in communication between nodes (as e.g. in a swarm). I’m guessing that what they are trying to protect against is already mitigated on resin.io (the server-to-device communication, since it’s going through a VPN). I’m not sure if it would even apply to the Docker use case as it is currently done on devices.
On the other hand, it’s definitely an important area to consider and if possible improve upon (thanks for the suggestion, and keep 'em coming!:). Can you tell us a bit more about how are you using Vault in your work flow? What sort of threat model you are protecting against? Context and use case would help us figure out better solutions.
Sure! I’m using Vault to hold secrets (specifically certs and keys for Logstash), which are retrieved by the application on a Resin-managed endpoint, using environment variables to define the Vault URL, credential path, and access token. If I could avoid the use of Vault and access the keys from the filesystem (is a read-only volume in RAM a crazy idea?) that would simplify the application running on the device substantially. I could probably shove them into environment variables, but it gets weird and unwieldy substituting carriage returns in environment variables so a certificate will unpack like you want it to.
Just a quick comment reading that, when projects needed such env vars conversions, we usually did base64 encoding/decoding, then there’s no substitution need, eg. see our AWS integration guide in the docs (as AWS IoT needs certificates too). That works well for that particular angle.
Seems like there’s some internal discussion about this secret storage, let’s see what comes out of it, will keep you posted too! 
@ashmastaflash I’d not come across Vault before, it looks like a very interesting tool! I’m presuming you’re hosting the Vault store in Consul (or similar) somewhere in the cloud? If so, is there any technique for you to access to the secrets within the Vault in the event that you go offline?
We have a particular requirement for storing a key which we have to ensure is absolutely secure, normally we do this with an encrypted file system, Vault looks quite a lot more flexible, but our use-case requires access to the key even if we currently don’t have network connectivity…Not sure if this is possible, short of locally hosting the Vault back-end?
Thanks for any advice!
Hey @cmoss, Sorry for the lapse! I write the secrets to ramdisk when the device initializes, which makes network connectivity a requirement on boot. If you need to be able to boot without connectivity, Vault run locally still probably isn’t the best option because you’ll have to unseal the secret store… which requires three (default, can be adjusted IIRC) of the five unsealing tokens before you can get at the secrets stored inside. So you’d have to have those unsealing keys somewhere… maybe in environment vars… and it’s a tall order getting things to look elegant without sealing the can opener inside the can, so to speak. Have you considered Yubico’s HSM, or storing a static password in a Yubikey? If having a hardware token as a requirement for offline initialization isn’t unbearable, this may be an option.