Use vault in concourse.suse.dev

[viovanov]

Is your feature request related to a problem? Please describe. We have too many sources of secrets. Everything should be vault.

Describe the solution you'd like Use curl, the vault CLI or a resource like this one.

Other option is https://concourse-ci.org/vault-credential-manager.html#vault-credential-manager on the concourse instance, with v1 secrets, instead of changing all the pipelines.

The solution should allow a pipeline to reference keys from multiple secrets, not just one. We want to have granular secrets #1608

[thardeck]

After reading up I would suggest to use the Concourse internal resource, so we do not have to add an additional resource to every pipeline (this would make a quick deployment of pipelines very cumbersome). We have to create a new structure in Vault anyway for #1608 so we can directly use a v1 and the other resources are also not that well maintained as it seems like

[mook-as]

I also think the Concourse built-in credentials manager is a better fit; if we used an external resource, they tend to emit the secrets as files (because they don't have any other way to emit them), which makes the usage difficult.

The downside is that there's only one auth token per pipeline in this case; this means we'll effectively need to let the concourse (vault) token have free reign, since it will need to be able to access any secret that any pipeline needs.

[mook-as]

Hmm, just found go-vln which sits as a proxy between concourse and vault, and provides

• KV v2 support
• Ability to change the vault secret paths (so that we can let concourse do its thing, and then actually redirect each entry to the proper place).

I have not actually tried it, though; I can't even find good documentation.

[jandubois]

which sits as a proxy between concourse and vault

I find the idea of a proxy in front of a secrets store somewhat scary from a security perspective.

[viovanov]

See if this can help: https://github.com/hashicorp/vault-k8s

[mook-as]

Started https://github.com/cloudfoundry-incubator/kubecf/pull/1645 for discussion, to make sure we agree on the direction before implementing things (so we can be sure we've got a design that will work for the various relevant cases).