best way to pass sensitive info in docker contaner

[Hridyesh Pant]

Hi,

I’m looking for some guidance on storing sensitive user names and passwords so that they can be used within a Docker Container.

1.       Decrypt during Docker build stage so that container is ready for us, or can we just pass these values into the Container via environmental variables.

2.       Decrypt during Container deployment/instantiation.

3.       Decrypt at runtime for each and every use.

we have vault setup but we are not sure how we can solve above use case using Vault.

looking vault documentation not giving much details.

If any solve this issue how to pass sensitive information in docker container using Vault?

--Hridyesh 

[David Adams]

In general you'd want the secrets to never hit the disk, so #3 would theoretically be best.

Check out this pattern: https://www.hashicorp.com/blog/vault-cubbyhole-principles.html

In summary, my understanding of the above pattern is that whatever process of yours that's starting the docker containers could create a token with the Vault policies your app needs, call it Token One, then create a two-time limited use token, call it Temp Token, and store Token One in Temp Token's `cubbyhole/` storage. Then pass Temp Token to the docker container as an env variable or something. Then in your container's startup, look in Temp Token's cubbyhole for Token One. At this point Temp Token will be expired and useless, so if it worked, then you can be certain that Token One is known only to your container. If Temp Token is already expired when your docker container tries to use it, then you know it was intercepted and you can send an alert to the admins.

Even simpler, if your containerized app just needs one or two one time secrets and not long-term access to Vault, you could skip generating Token One, and just put those secrets into Temp Token's cubbyhole.

Obviously this just moves the bootstrap question back a step (to the process that manages the docker containers), but eventually you'll get to somewhere that's human manageable. :)

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
 
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to the Google Groups "Vault" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/805261e0-f651-4cd2-9719-a544e6807d3e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

David Adams | Systems Administrator

E: dad...@instructure.com

[Hridyesh Pant]

Thanks David for the explanation.

There are two operation we do with Vault

Storing the secret

Retrieving the secret.

I am looking is some suggestion about the complete workflow where both the task (store and retrieve)  can be performed in term of ACL ,getting authentication token, can retrieve particular secrete from authentication token . 

We have following two workflow: 

1. Application A want to store secret  
2. Application A deployed using EC2 instances 
3. Application A want to access secret (no there application can access Application A secret) 

Docker ECS /deployment :

1. Application B want to store sercte 
2. Application B deployed via AWS  ECE as docker  
3. Application B want to access secret (no there application can access Application A secret)

If will be really helpful if I can get some idea to implement above use case.

If we use  App-id/user-id mode: 

we need to mapped app-id-user-id and secret path at the time of storing the secret. Now how do we share these app-id and user-id to application . if they simply use this in application , then any one can see these value and it is similar to have plain text passwd

Document  says : An out-of-band process run by security operators map unique user IDs to these app IDs. Example: when an instance is launched, a cloud-init system tells security operators a unique ID for this machine. This process can be scripted, but the key is that it is out-of-band and out of reach of configuration management. (Path: map/user-id/)

Does it means only some Admin guys can have permission to store the secret and put app-id in configuration file. this task will mapped app-id and policy (to access that particular secret)

and when application launch , it will contact one external service (via HTTP or REST call)  to mapped app-id and user-id . 

Issue is how we can sure the only valid application are making call to this external service?

Cubbyhole model:

i could not see that option when i auth backed tab in https://www.vaultproject.io/docs/auth/index.html , does it still support?

Although the link you shared  have this information and document says :

1. A process responsible for creating Vault authentication tokens creates two tokens: a permanent (perm) token and a temporary (temp) token. The perm token contains the final set of policies desired for the application in the container. The temp token has a short lease duration (e.g. 15 seconds) and a maximum use count of 2.
2. The temp token is used to write the perm token into the cubbyhole storage specific to temp. This requires a single write operation, reducing the remaining uses oftemp to one.
3. The invoked process gives the temp token to the application management engine (for instance, Docker), which starts the application and injects the temp token value into the application environment.
4. The application reads the temp token from the environment and uses it to fetch theperm token from the cubbyhole. This read operation exhausts the temp token's use limit, the temp token is revoked, and its cubbyhole is destroyed.
5. what will be  the process storing the secret first , what policy we need to apply so that that perm token can only access particular secret path or this perm token have permission to access any secret?  

how we can sure the only valid application are making call to this external service which are responsible to create temp and perm token?

—Thanks

[Jeff Mitchell]

Note that in the next release of Vault (and in master now) you'll be
able to automatically have any response (outside of sys/) be wrapped
inside a cubbyhole for you. Writing a side process to do this will not
be necessary!

Best,
Jeff

> https://groups.google.com/d/msgid/vault-tool/CAJ4Phq9x4_C6bqz0F8H-R-Svm%2Bt24cRE5Z6vScPRiNWvk8YeOA%40mail.gmail.com.