we would like to connect our devices to AWS IoT and other AWS services. The idea is to use one Certificate and Keyfile per Device as an authentication means. I would not want to store the private key on BalenaCloud to make it available for Docker services. My opinion is that this kind of credentials should be kept in exactly one place, the device itself.
Let me know if you disagree and why.
If not, where is the best place to store these credentials when provisioning the device? For the moment I want to assume that storing the key on the filesystem is secure.
Hello, Could I ask what you main concerns are with using the normal cloud mechanisms for this? Limiting the storage of the key to the device alone would not totally remove the cloud from the equation, as any files on the device can still be accessed via the cloud shell. There is also the question of physical access to the device - does the device provide some form of secure storage?
I was under the impression that it would be more secure to store the credentials only in the physical location where they will be used instead of storing a lot of credentials in a central place.
But I understand your argument. If I have access to the cloud, I actually have root access to the device, and I also have access to any container using the credentials.
Does that mean you encourage to put keys into service variables instead? I had done that before and it works. What I did was to convert a key file so that all line breaks are escaped and then put it into a variable as a string.
There probably is a more elegant way to achieve this, could you point me in the right direction?
Hey @bvetter, for my own projects I store credentials as environment variables in balenaCloud. Similar to what you do, I usually encode the credentials / key in Base64 to handle line breaks.
Where and how to store credentials are definitely frequently asked questions. You could see my teammates discussing these in several forum posts like:
You could look into encrypting the credentials before storing them as environment variables. Then the application decrypts into memory at runtime. In any case, you need to have physical security to device access. Else, the physical attackers with access to your device could still retrieve the decryption key.
Couple of balena users expressed their satisfaction with using a 3rd party solution like Vault. You start an application with a short-lived token in the environment to allow it to go to vault and get whatever secrets it needs. Later attackers reading the environment variable (either by spawning a shell in the container, or with docker inspect on the host) only get an expired token, and they would have to pull secrets from the memory of the running process inside the container, which is a fair bit harder.
I know couple of my teammates have been discussing potential improvements here to reduce friction. I’m going to raise your interest in our internal systems – in order to create more visibility on these asks and also to message you once we possibly release new features on this topic.