Software/infrastructure requirements should go into more detail about passing secrets to containers

[proycon]

@jblom said:

About the k8s secrets etc. (Maarten van Gompel & Slava Tykhonov) We use them, but they are not really that secure by default. E.g. we now use secrets and inject them as environment variables in running containers, however, simply running env on the running container shows all secrets in plain text.
I think the service/infra requirements should indeed go a bit more into detail on this topic (e.g. read this https://blog.aquasec.com/managing-kubernetes-secrets) .

@4tikhonov added:

A set of Common Software Quality Assurance Baseline Criteria for Research Projects developed in EOSC Synergy project https://digital.csic.es/bitstream/10261/160086/10/sqa-baseline-v4.0.pdf

#102

[proycon]

@mmisworking Do you already have certain ideas on this? Certain best-practices already in use at KNAW HuC perhaps?

[proycon]

I think this is the last remaining issue that is still open for the software/infrastructure requirements. I don't really have too much experience on best practices regarding this so I'm hoping to get some input from others who have worked with this and can help amend the document.

I do think we should discourage using environment variables for secrets (interesting article: https://diogomonica.com/2017/03/27/why-you-shouldnt-use-env-variables-for-secret-data/)

[proycon]

I've been reading and thinking a bit more on this and how what this implies for developers preparing containers.

If I understand things correctly, a secret engine (like https://github.com/hashicorp/vault-k8s which @mmisworking suggested) makes secrets available via mounts (usually tmpfs, so in-memory) and ensures that these are kept properly encrypted until read.

For the underlying software, this probably means that instead of passing an environment variable like $SECRET_PASSWORD which would contain a secret in plain text (=not secure and not in accordance with our requirements) you pass it an environment variable like $SECRET_PASSWORD_FILE which points to wherever the secret was mounted (which is infrastructure/deployment specific). There is therefore still an environment variable involved but it's no longer sensitive. The software reads that file to get the actual data and, whatever secret daemon is used ensures that the software (and only the software) can transparently access the file.

@mmisworking @ddeboer does this seem correct to you guys?