4

We are trying to run concourse with Vault. Reason for using vault is to store secrets in a a secure way. Some of the parameters we want to store in vault are github private key, to get access to the github repositories, as well as username and password for CloudFoundry access. These kind of secrets are not expected to be shared...

Sounds all very nice, however, it is pretty easy to recover the content of stored secrets in vault, when having access to the concourse team.

Example: Storing following in vault

vault write concourse/main/cat-name value=Garfield
vault write concourse/main/dog-name value=Odie

Running the next pipeline will show the contents of the stored parameters:

jobs:
  - name: show-animal-names
  plan:
  - task: show-animal-names
  config:
    platform: linux
    image_resource:
      type: docker-image
      source:
       repository: busybox
    params:
      CAT_NAME: ((cat-name))
      DOG_NAME: ((dog-name))
    run:
      path: env

Which results in: 

fly -t concourse trigger-job -j publishing-outputs/show-animal-names -w
started publishing-outputs/show-animal-names #1
initializing
running env
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
HOME=/root
CAT_NAME=Garfield
DOG_NAME=Odie
USER=root
succeeded

This way, also username, passwords, github-private-keys, and all other stuff stored in vault, can be retrieved for everyone who was granted access to update pipelines in concourse.

Is there a way to use concourse and have these kind of secrets kept secret, so not shown?

Daniel Mann
  • 57,011
  • 13
  • 100
  • 120
Wall-E
  • 41
  • 1
  • 2
  • We faced the same problem. I don't think it is possible. To reduce exposure, we use multiple Concourse teams. Consider also that if someone can change the pipeline file, it means either it has write access to the underlying git repo, or has access to Concourse, so he/she is already trusted and can already write to the git repo, so getting the SSH private key buys him nothing. Another thing we do is that we have a different SSH key per each repo, to reduce exposure. Vault is still super-useful, keep using it! It avoids storing secrets in repos and it hides secrets from "fly get-pipeline" – marco.m Jun 06 '18 at 13:17
  • You are right about the fact that getting the SSH private key doesn't buy him nothing, however, at that moment. When someones access has been withdrawn, he can still get access using the key used in the concourse pipeline when he stored the info. This would mean that whenever someone leaves the company all stored secrets needs to be replaced. Not a very nice action. – Wall-E Jun 07 '18 at 13:58
  • Good point! But this is, in my understanding, the reality. If you think about it, the only way for Concourse not to leak the secrets via your example with env vars is to be aware of what a git repository is, that is, to avoid using a resource. And this goes against Concourse philosophy. Did you know that in this period Concourse is deciding about "resources 2.0" ? You might want to comment there: https://github.com/concourse/rfcs/pull/1. Also I would appreciate if you brought this question on the Concourse forum to raise visibility https://discuss.concourse-ci.org/ – marco.m Jun 07 '18 at 18:06

2 Answers2

0

Have you considered CredHub and it’s integration with Concourse?

https://concourse-ci.org/creds.html#credhub

Armakuni
  • 11
  • 1
  • I don't think using CredHub instead of Vault will help in any way. Same kind of secrets lookup is used for CredHub as for Vault, so the above showed pipeline will still reveal the stored secrets. Doesn't matter where they originate from. – Wall-E Jun 07 '18 at 13:30
-1

Isn't it also possible to get the full secrets by doing a fly gp -p my-pipeline or is Concourse redacting the content of the Credhub/Vault referenced secrets?

I also think there should be more protection of secrets in Concourse.. This is not only related to secrets that are received form Vault or Credhub. I also feel not comfortable to give every user that has access to the team the possibility to receive all secrets from the pipeline credentials files i invoked with fly sp -p... -l <secret-file>

gdenn
  • 501
  • 1
  • 5
  • 12
  • 1
    To answer your question, it is enough to try fly get-pipeline :-) Secrets ARE redacted from fly get-pipeline, as long as fly set-pipeline doesn't sets them and instead you leave setting them to the credentials manager. – marco.m Jun 27 '18 at 11:56