Better Secrets management workflow

[donspaulding]

Issue details

I'm looking for ideas on how to manage secrets and configuration in kubernetes.

I work on a dev team where historically we've managed our credentials, secrets, and environment-specific config files by storing them alongside our application code in our project's source control repos. I'm tasked with updating our workflow to conform to 12-factor app best practices, and so I'm looking to have the environment provide the appropriate configuration to our containers at runtime

Environment

Our current project file structure is something like this:

project/
 |-- conf/
     |-- dev-config.py
     |-- prod-config.py
     |-- config.py      (symlink to prod-config.py or dev-config.py created by ansible)
 |-- app/
     |-- settings.py    (always imports settings from ../conf/config.py)

The k8s Way

It appears as if k8s Secrets and ConfigMaps with volume mounts are intended to solve this from the container's perspective. I've had some success with creating a Secret and then mounting it into conf/config.py. Unfortunately, there seem to be several drawbacks to this approach.

Observed result

1. volumeMounts override all files within the project/conf/ directory.
2. All secrets are available to any container to be mounted.
3. The dashboard allows editing of ConfigMaps and Secrets, but not creating them?
4. Editing secrets requires the developer to base64 decode/encode the values.

Expected result

In an ideal world, I would be able to:

1. Create a secret from the dashboard (just the key?).
2. Add the value of the secret with an editor (i.e. specify the contents of project/conf/config.py)
3. Not have to use base64 from the UI.
4. Be able to map a single secret's key/value into a single file in a directory (maybe solved in Projecting single files from volumes into a container's FS kubernetes#19764 ?)

Comments

I'm new enough to the Kubernetes world that I don't even know if I'm asking the right questions, let alone getting close to the right answers. I'd appreciate any pointers to better solutions in this space. As I go through the process of migrating these apps, I'm trying to stick close to the native k8s stack when looking for solutions to my problems. I'm pragmatic though; I'll use whatever solves the problem. And in this case, I think k8s secrets are an almost perfect mechanism for the container, it's just that they leave a lot to be desired from a dev workflow standpoint.

[jwforres]

I agree that you shouldn't need to use base64 as an end user of a UI. The UI can do the encoding/decoding for you. The one caveat is that some base64 encoded secret data can actually be binary content and won't decode to readable text. In openshift we do detection to see if the base64 decodes to valid text or not. https://github.com/openshift/origin-web-console/blob/master/app/scripts/services/secrets.js#L68

Also of note, a change was made to the API to make it easier to create/update secrets, there is now a dataText (or textData?) attribute that you can send in place of the normal data attribute, this allows you to send plain text on a create/update which will then get base64 encoded server-side and stored into the data field.

As far as what an end user should see for create/update, I would expect a multiline editor / file upload combo that lets you pick a file to send for the secret or type in the content yourself.

The issue with secrets (and config maps) as volumes overwriting the entire directory is still an issue, there are workarounds as suggested in kubernetes/kubernetes#19764
copying the file on container startup is an option (but you have to bounce the pods to pick up the change). cc'ing @pmorie who i've already been bugging about this recently :)

[cristim]

The base64 is a PITA, and pretty much defeats the purpose of allowing the editing of secrets from the web interface.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[maciaszczykm]

This is already done.