Assess secret storage systems for Lagoon

Currently it’s not possible to store secret environment variables across an entire OpenShift project. Each new environment that is created for a new PR or branch needs to have ENV vars set manually in the deployment. Could we move to Vault to manage this instead of env?

Based on some investigations in our project, the following steps outline what may be needed to achieve a production level integration of Vault.

Install Consul.

** https://github.com/kubernetes/charts/tree/master/stable/consul

Install Vault.

** https://github.com/kubernetes/charts/tree/master/incubator/vault

Install the Goldfish Vault Web UI.

** https://github.com/kubernetes/charts/tree/master/incubator/goldfish
** https://github.com/Caiyeon/goldfish

Configure the Vault Kubernetes Auth Backend.

** https://www.vaultproject.io/docs/auth/kubernetes.html
** This will allow Kubernetes service accounts to authenticate to Vault.

For each application that is to use Vault stored secrets.

** Create a `ConfigMap` with a file defining the secrets to be consumed.
** Change the Dockerfile ENTRYPOINT for the workload so that `vaultenv` is used to fetch the secrets from Vault and store them in environment variables.
** https://github.com/channable/vaultenv
** The section “Exposing Secrets to Applications” from this article goes into more detail about using `vaultenv` - https://www.elastic.co/blog/kubernetes-vault-integration-devops-team

[Schnitzel]

Thanks for this @kurtfoster There is also #65 which covers another idea of this.

Will definitely look into Vault and check how we can use that in a PaaS enviornment where multiple clients need access to the Vault but should not have access to each others Secrets

[Schnitzel]

we talked about this again during lagoon tech sync:

• the easiest and highest adding of security would be to encrypt the env variables in the lagoon api db and decrypt them when they are loaded.