use vault for storing credentials

[igalic]

we should use vault for storing our forge credentials

@daenney offered to write a small service for retrieving a travis secret from the vault
so anyone could use it to update their secret.

[daenney]

Yes. So the idea is we have a vault with our keyspace for puppet-community (or $name). We'll have keys in there like forge_password etc. for which we can hand out a read-only key to every module that joins us which in turn can be encrypted by travis encrypt and stored there.

The owners of the org will also have a key that gives them write access to the secret so we can update it when needed without anyone else needing to know about the change of credential or it disrupting the release process.

[nibalizer]

That doesn't make any sense to me.

1. We only have one password for the puppet forge, all modules share the same password.
2. An encrypted file in a git repo is infinitely simpler than a secret service.
3. Assuming we're talking about hashicorp vault, that was never intended to be run on the public internet.

[daenney]

1. That might not be true in the future and having individual credentials that we can use to revoke access to secrets has benefits
2. As long as we rely on PGP for it, no it is not. Case in point the current dance that needs to happen every time someone needs to release a new/transferred module
3. I wasn't specifically talking about Vault the product, there's a few that implement a similar paradigm

[nibalizer]

PGP isn't that hard. It's not great for encrypting emails. It's actually really good at having a secret password encrypted to N individuals.

[nibalizer]

We already run pcci, so maybe the way forward is to remove travis from the release pipeline all together, run our own release pipeline on servers we control and inject credentials that way.

[daenney]

Yeah, I've actually been thinking the same. I'm curious if we couldn't just spin up a Drone CI instance ourselves without much trouble. Or a Go (the thing by Thoughtworks). And see if we can get the Beaker testing in there too by leveraging Docker. They've done some recent work allowing you to run Beaker "as is", so without it needing to orchestrate remote machines.

[nibalizer]

Whatever problems GPG has around being hard to use, git is far, far worse.

[daenney]

Anecdotal evidence between the amount of people that manage to use git every day vs GPG invalidates that statement 😛.

[igalic]

sick 🔥

[daenney]

I'm going to close this one for now, I think we need to revisit it once we have hammered out our different processes a bit more. I'm hoping that when we do so we'll be able to consolidate the services that need credentials to very few instead of every module so this issue will be moot.