Document or improve custom bosh release process

[jmcarp]

We're currently using a custom process for bosh releases: instead of checking changes to the releases and .final_builds directories into source control, we push them to s3, then pull them down again the next time we update the release. This is confusing because it's non-standard, and because sometimes we have conflicting release artifacts in git and in s3 (for example, when we build a community release). I'd like to either document this process or think about simplifying it. Either task might be good for pairing with @rememberlenny.

@LinuxBozo @sharms: can you remind me why we aren't supposed to send PRs from concourse? As long as concourse can't push to master, what keeps us from doing this? I'm guessing the answer is Because Compliance, just want to verify.

cc @cnelson

[LinuxBozo]

@jmcarp The concourse having no git access was due to two issues:

1. control/creation of the account needed to generate the necessary github auth token
2. lack of properly protected branches (what was in place at the time was just limiting force push)

2 has been solved for us by recent github features, but 1 I'm not 100% sure is a solved problem that meshes with policy. I agree the current process is not great, and was only supposed to be temporary so we could move forward until we had more time to handle it properly. This was also supposed to roll into the flow we have for deploying CF, in that manifest changes that successfully were tested in staging got an automatic PR for staging->master

[cnelson]

Can we solve 1 by creating a google group who's email address we use to create the account?

Using a google group means it's not tied to an individual who can leave the organization, and access controls on the google group would allow us to control who can reset the password, etc.

[LinuxBozo]

The biggest policy blocker is MFA is required on the account to be part of the org. If we can justify somehow being outside the org, maybe we could get around that? An account that relies completely on forks?

[cnelson]

Can we create an account with TOTP 2FA, use one of the many simple command-line TOTP clients to generate codes when we need them and keep the cli's secrets in our existing secret store?

Concourse wouldn't need to use TOTP to auth for any operations, it'd operate using tokens or private keys just like we do when performing operations from the command line.

We'd only need to get at the TOTP secret when we need to login to to the UI to rotate tokens/keys on the account.