Secret Management

[will-chan]

Rancher needs to be able to support a way to store secrets securely (db passwords, api credentials, etc.) and then let it be made available to containers and services.

Revised: 8/26/2016

• Rancher will support secrets as a first class object within an environment.
• Rancher will delegate encryption/decryption to a remote service that can use multiple backends. (ie. None, Local and Vault Transit)

Flow will look something like:

1. User creates a secret via CLI something like:
   rancher secret create name [—from-file file ] [plaintext]
   creating a secret scoped to a Rancher environment.
2. User deploys application requesting secrets via labels on FlexVols or top level fields for Cattle.
3. The FlexVolume implementation will call out to the Rancher secrets API to fetch the required secrets. These will be passed as metadata to the volume.
4. When FlexVolume requests secrets they will be encrypted with host level key that is shared(because it has been created by Rancher).
5. The FlexVolume driver will use its private key on the host to decrypt the data received from the secrets API.
6. The application can consume the secrets from a file on disk. This can be defined via label and/or field, and could be backed by a volume provided by either Docker or K8s.

[blaggacao]

Maybe I'm late to drop in, but I'm stuck with exactly this. I hope this is the right issue to comment on out of: #2060 #1971 #186 #744

From a Docker perspective, its on the radar: moby/moby#13490

Having had a closer look at http://square.github.io/keywhiz/ and https://vaultproject.io I would suggest vault as it excels in UI over the other, also we have seen good stuff from hashicorp in the past.

I'm not so much into the Rancher System Docker Daemon yet, so this might seem silly, anyhow, I'll copy for reference a minimal configuration of a vault server. This could go into the rancherOS istself, while using the excisting rancher distributed storage mechanisms...

backend "consul" {
  address = "127.0.0.1:8500"
  path = "vault"
}

listener "tcp" {
 address = "127.0.0.1:8200"
 tls_disable = 1
}

See also for docker-specifics: hashicorp/vault#165

And how to deploy: https://vaultproject.io/intro/getting-started/deploy.html

[boedy]

What is rancher current stance on Secret Management? Where do I put my my access tokens, database passwords?

[kaos]

+1, this needs to be addressed. :)

[dmzaytsev]

+1 I guess 1.0 will be released not soon
but Secret Management is an important feature

[caussourd]

+1 definitely need this feature

[raphink]

👍

[rvion]

+1

[taketnoi]

+1

[fbrbovic]

+1

[bluemalkin]

+1

[markw01]

+1

[frekele]

+1

[jmls]

any news on this ?

[maxnoe]

+1

[jtsaito]

+1

[jandragsbaek]

+1

[fmorency]

+1

[cpoole]

FlexVols are nice but that requires an init script in the container that will fetch the secrets from the vol and inject them as environment variables before starting the actual program. This makes using community images from docker hub almost impossible.

It would be nice if the secrets bridge could inject a secret into a container at run time. For example you give rancher the two files

docker-compose

web:
  image: mywebserver:0.0.1
  environment:
    - DATABASE_ADDRESS=mydatabase.mysite.com

rancher-compose

web:
  scale: 1
  environment_secrets:
    - DATABASE_PASSWORD= secrets.backend_type.secret_name

Then before executing that docker compose file rancher would add in the full value of the DATABASE_PASSWORD, generating:

web:
  image: mywebserver:0.0.1
  environment:
    - DATABASE_ADDRESS=mydatabase.mysite.com
    - DATABASE_PASSWORD=asddfjasldfkjsdfsdf

In the ui, when you click to see the docker and rancher compose files you would see the un-interpolated versions.

Finally rancher would know which stacks are allowed to access which paths because when you created them with the command rancher secret create name [—from-file file ] [plaintext] you could add the stack name to keep it scoped: rancher secret create -environment=environment_name -secret_name=name -stack=mywebsite [—from-file file ] [plaintext]

Is there some major security loophole this would introduce that I am not seeing?

[Austriker]

+1

[theinrichs]

Maybe this is interesting for this topic: moby/moby#27794

[ekristen]

I have a few recommendations ...

• I would really like to see vault as the secrets management backend, but +1 to a modular secrets management setup.
• I would really like to see the ability to interpolate environment variables from the secret backend(s)
  • IE MYSQL_DATABASE={{secret.vault.path-to-secret}}
• I would really like to see the ability to use a template system to write secrets to a file inside the container, something like golang templates would work great.
  • the reason for this is that there are different way configuration files are loaded and being able to adapt to already existing formats without having to write special code in applications to allow for a unique format that only rancher does would be awesome, it'll also give admins better control of how and where secrets are placed.

[yeta-io-ceo]

+1

[deniseschannon]

We are targeting to have an experimental version of secrets management available in 1.4.0.

[deniseschannon]

@galal-hussein Can you test with the next rancher RC v1.4.0-rc4?

[sangeethah]

#7607

[galal-hussein]

Rancher version 1.4.0-rc8, tested secret management workflow for both localkey and vault backends, all test cases passed successfully.

[cryptiklemur]

Multiple requests for being able to automatically inject these secrets into the environment...

Did that request see any progress?

[tnaduc]

+1
I would like to have a feature to add secret file such as google cloud service account json key.