How pass credentials to containers

503 views
Skip to first unread message

Francisco Javier Romero Mendiola

unread,
Oct 4, 2016, 6:53:19 AM10/4/16
to Vault
I am thinking about how to pass credentials to containers and I have watched next video of Jeff:


I have no clear how it works. What scheduler and scheduler agent are
















Regards.
Francisco

Vishal Nayak

unread,
Oct 4, 2016, 9:13:07 AM10/4/16
to vault...@googlegroups.com
Hi Francisco,

I'm only putting my 2 cents here..

Jeff's talk is very generic to represent wide variety of infrastructure setups. For the purposes of this discussion, an analogy can be drawn towards Nomad (https://www.nomadproject.io/). Scheduler maps to Nomad servers, and the scheduler agent maps to Nomad clients. Nomad server will create Vault tokens (response-wrapped), and injects the wrapped-tokens in to the jobs, which can very well be a container job, all the while retaining wrapped-token-accessor with itself so it can revoke the token when the job completes.

Regards,
Vishal

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/231bdb76-cdf0-4b05-93e3-3463dc19b1eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
vn

Francisco Javier Romero Mendiola

unread,
Oct 6, 2016, 5:46:13 AM10/6/16
to Vault
You are right Vishal but I have no clear how scheduler relies from Container to take the temporal token.

Regards.
Francisco


On Tuesday, 4 October 2016 15:13:07 UTC+2, Vishal Nayak wrote:
Hi Francisco,

I'm only putting my 2 cents here..

Jeff's talk is very generic to represent wide variety of infrastructure setups. For the purposes of this discussion, an analogy can be drawn towards Nomad (https://www.nomadproject.io/). Scheduler maps to Nomad servers, and the scheduler agent maps to Nomad clients. Nomad server will create Vault tokens (response-wrapped), and injects the wrapped-tokens in to the jobs, which can very well be a container job, all the while retaining wrapped-token-accessor with itself so it can revoke the token when the job completes.

Regards,
Vishal
On Tue, Oct 4, 2016 at 6:53 AM, Francisco Javier Romero Mendiola <fjro...@paradigmadigital.com> wrote:
I am thinking about how to pass credentials to containers and I have watched next video of Jeff:


I have no clear how it works. What scheduler and scheduler agent are
















Regards.
Francisco

--
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.



--
vn

Jeff Mitchell

unread,
Oct 6, 2016, 9:15:17 AM10/6/16
to vault...@googlegroups.com
Hi Francisco,

Typically this is done either via environment variables created as
part of the container, or via placing secret(s) onto a ramdisk and
bind-mounting that into the container.

Best,
Jeff

On Thu, Oct 6, 2016 at 5:46 AM, Francisco Javier Romero Mendiola
<fjro...@paradigmadigital.com> wrote:
> You are right Vishal but I have no clear how scheduler relies from Container
> to take the temporal token.
>
> Regards.
> Francisco
>
> On Tuesday, 4 October 2016 15:13:07 UTC+2, Vishal Nayak wrote:
>>
>> Hi Francisco,
>>
>> I'm only putting my 2 cents here..
>>
>> Jeff's talk is very generic to represent wide variety of infrastructure
>> setups. For the purposes of this discussion, an analogy can be drawn towards
>> Nomad (https://www.nomadproject.io/). Scheduler maps to Nomad servers, and
>> the scheduler agent maps to Nomad clients. Nomad server will create Vault
>> tokens (response-wrapped), and injects the wrapped-tokens in to the jobs,
>> which can very well be a container job, all the while retaining
>> wrapped-token-accessor with itself so it can revoke the token when the job
>> completes.
>>
>> Regards,
>> Vishal
>>
>> On Tue, Oct 4, 2016 at 6:53 AM, Francisco Javier Romero Mendiola
>> <fjro...@paradigmadigital.com> wrote:
>>>
>>> I am thinking about how to pass credentials to containers and I have
>>> watched next video of Jeff:
>>>
>>> https://www.youtube.com/watch?v=R-jJXm3QGLQ
>>>
>>> I have no clear how it works. What scheduler and scheduler agent are
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
> https://groups.google.com/d/msgid/vault-tool/787729ef-8817-4655-8711-27cd48a18faa%40googlegroups.com.

Evan Wies

unread,
Oct 17, 2016, 11:24:22 AM10/17/16
to Vault
I haven't seen anything concrete on this, so I'll post what I started doing for injecting secrets while building containers from Dockerfiles.   

In this case, I have Docker DNS set up to use Consul via dnsmasq, so can use "vault.service.consul" to find it. 

Prior to the Docker build, I extract the relevant info and token-wrap it.   I have a helper script to make it easier on the command line; this outputs a wrapped token:

#!/bin/bash
# wrap_vault_token.sh

## TODO argument handling, error handling
MY_SECRET_PATH
="$1"
MY_TTL
="${2:-60s}"

# VAULT_TOKEN is already defined in the environment,
# it has permissions for MY_SECRECT_PATH

curl
-s -H "X-Vault-Wrap-TTL:$MY_TTL" -H "X-Vault-Token:$VAULT_TOKEN" "https://vault.service.consul:8200/v1/secret/$MY_SECRET_PATH" | jq -r '.wrap_info.token'

So I have already stored a Bitbucket SSH key in Vault at "bitbucket/my_repo" in the field "id_rsa".   I build the container like this:

docker build --build-arg BITBUCKET_TOKEN=$(./vault_wrap_token.sh bitbucket/my_repo) .

My Dockerfile has this in it:
# jq, curl, and ca-certificates are already installed
ARG BITBUCKET_TOKEN
RUN cd
/tmp \
   
&& mkdir -p /root/.ssh \
   
&& curl -X POST -H "X-Vault-Token:${BITBUCKET_TOKEN}" https://vault.service.consul:8200/v1/sys/wrapping/unwrap | jq -r .data.id_rsa > /root/.ssh/id_rsa \
   
&& chmod 600 /root/.ssh/id_rsa \
   
&& hg clone ssh://h...@bitbucket.org/my_username/my_repo \
   
&& rm /root/.ssh/id_rsa \
   
&& echo "the project is now cloned and there are no secrets hanging around"

Since everything happens in the same RUN command, the layer does not have the SSH key.  It does have the BITBUCKET_TOKEN, but that has one-time use and a 60-second TTL, so it's safe to have that information baked into the Docker image.

I think the one thing I wish in this is that the HTTP APIs allow field extraction so I don't need jq for this narrow use case.

-Evan 

Michael Fischer

unread,
Oct 17, 2016, 11:26:42 AM10/17/16
to vault...@googlegroups.com
Isn't it considered harmful to put secrets into Docker images?

--Michael

To unsubscribe from this group and stop receiving emails from it, send an email to vault-tool+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/5ad2af96-d873-49ef-be09-8eb7a51d16f7%40googlegroups.com.

Evan Wies

unread,
Oct 17, 2016, 11:29:57 AM10/17/16
to vault...@googlegroups.com
As the last line says, no secrets are laying around in the image because they are extracted and removed in the same RUN line.  The only "secret" that is persisted is the wrapped token which is single use and has a short TTL, so it is an irrelevant secret.

If I am wrong about this please let me know!

I didn't show it there, but after I clone, I build the project, and then rm the source.

-Evan
You received this message because you are subscribed to a topic in the Google Groups "Vault" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vault-tool/-nl973TywnI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CABHxtY5JvpuRLcKUrmyQ8tZryEnnRM0on8YanJJv44btuz40DA%40mail.gmail.com.

Michael Fischer

unread,
Oct 17, 2016, 11:33:35 AM10/17/16
to vault...@googlegroups.com
/tmp is not a tmpfs (RAM filesystem) in the Docker build context, so it's possible the token is still buried in the serialized filesystem image as a deleted block.  But yes, it's less worrisome than other cases.  My mistake for thinking it was in the image as a regular file.

To unsubscribe from this group and all its topics, send an email to vault-tool+unsubscribe@googlegroups.com.

--
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+unsubscribe@googlegroups.com.

Michael Fischer

unread,
Oct 17, 2016, 11:42:33 AM10/17/16
to vault...@googlegroups.com
Correction: /root in your case, not /tmp.  Still not a tmpfs though.  It really depends on your base image; I checked busybox and neither is a tmpfs.

There might be a hack you can implement where you mount a tmpfs, write the SSH private key there, then wrap your git command with `GIT_SSH='ssh -i /path/to/private/key/on/tmpfs'`.  That'd be safer.

Evan Wies

unread,
Oct 17, 2016, 11:44:47 AM10/17/16
to vault...@googlegroups.com
Thanks for clarifying that.   I'll look into integrating it into the solution.
To unsubscribe from this group and all its topics, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CABHxtY4PfVkRkMQVNvQVbHKbNTWbk_EvzJV8%2Bvk45u2ztAyvfQ%40mail.gmail.com.

Evan Wies

unread,
Oct 19, 2016, 10:26:01 AM10/19/16
to vault...@googlegroups.com
When building containers, `docker build` doesn't run privileged, so it cannot mount a tmpfs.

When running containers, `docker run` has a --tmpfs option which makes it easy to introduce tmpfs mounts, so run-time secrets could be stored there.
To unsubscribe from this group and all its topics, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CABHxtY4PfVkRkMQVNvQVbHKbNTWbk_EvzJV8%2Bvk45u2ztAyvfQ%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages