Docker config including password and other sensitive information should be encrypted

[danieland]

Docker config (/boot/config/plugins/dockerMan/templates-user) may have some sensitive data, such as the database config (username & password ) it connected to.

It stores in usb flash as plain text but should be encrypted.

[trilobytelion]

Since it is a configuration that the system should use automatically, encrypting that config will come with some significant tradeoffs.

 

I've been working on setting up some docker containers and pass some private data, so I would love to hear more thoughts on how other people are approaching that problem.

 

But first of all, what is your usecase and what threat are you trying to mitigate? In my case I don't consider that a big deal, because I don't care about physical security (well, I do care, but if someone gets into my home I have bigger problems   ).

 

How I'm thinking about the problem:

• If that config is encrypted in a "transparent" way and everything works without user intervention, in that case the decryption key must me somewhere and at all effects it is the same as plain text. You are just making the attackers life slightly more difficult.
• It is encrypted with a user password, in that case the user would need to put that password to start the system/docker. Full disk encryption with password at boot and storing the config there should be the easiest out of the box way to solve that problem without many changes. But rebooting a remote system is out of the question. In my case it is a tradeoff I'm not willing to accept.
• As something in between, you could try to define secure dockers and ask for a user password when running them. But in that case maybe it is easier embed that as part of the docker image instead of the docker system.
• Other option could have a "secret managent" service, but apart from the complexity, you'll still need to think about how to start it up and operational tradeoffs.

 

In my case I'm settling with a combination of docker parameters and files in binded volumes.

[danieland]

On 9/16/2023 at 3:47 PM, trilobytelion said:

Since it is a configuration that the system should use automatically, encrypting that config will come with some significant tradeoffs.

 

I've been working on setting up some docker containers and pass some private data, so I would love to hear more thoughts on how other people are approaching that problem.

 

But first of all, what is your usecase and what threat are you trying to mitigate? In my case I don't consider that a big deal, because I don't care about physical security (well, I do care, but if someone gets into my home I have bigger problems   ).

 

How I'm thinking about the problem:

• If that config is encrypted in a "transparent" way and everything works without user intervention, in that case the decryption key must me somewhere and at all effects it is the same as plain text. You are just making the attackers life slightly more difficult.
• It is encrypted with a user password, in that case the user would need to put that password to start the system/docker. Full disk encryption with password at boot and storing the config there should be the easiest out of the box way to solve that problem without many changes. But rebooting a remote system is out of the question. In my case it is a tradeoff I'm not willing to accept.
• As something in between, you could try to define secure dockers and ask for a user password when running them. But in that case maybe it is easier embed that as part of the docker image instead of the docker system.
• Other option could have a "secret managent" service, but apart from the complexity, you'll still need to think about how to start it up and operational tradeoffs.

 

In my case I'm settling with a combination of docker parameters and files in binded volumes.

I prefer the second way, since the array can encrypted with key, the docker config can also be encrypted in flash drive and decrypted in memory while we start the array. The docker can only be started after the array started, I don't understand why you say "rebooting a remote system is out of the question" ?

[danieland]

So I found a workround for those concern about this issue:

Docker support --env-file parameter to import env from file. We can put env file contains those secrets in an array file.

Array support encrypt, and docker can only be started after array started.