Evaluate options for secret support #29
Comments
alexellis
added a commit
that referenced
this issue
Jan 27, 2020
Adds secrets support and binding of secrets at runtime to functions. Files are written in plain-text to a 0644 permission folder which can only be read by root and the containers requesting the secret through the OpenFaaS API. Tested by deploying an alpine function using "cat" as its fprocess. Happy to revisit at a later date and look into encryption at rest. This should be on-par with using Kubernetes in its default unencrypted state. Fixes: #29 Signed-off-by: Alex Ellis (OpenFaaS Ltd) <alexellis2@gmail.com>
alexellis
added a commit
that referenced
this issue
Jan 28, 2020
Adds secrets support and binding of secrets at runtime to functions. Files are written in plain-text to a 0644 permission folder which can only be read by root and the containers requesting the secret through the OpenFaaS API. Tested by deploying an alpine function using "cat" as its fprocess. Happy to revisit at a later date and look into encryption at rest. This should be on-par with using Kubernetes in its default unencrypted state. Fixes: #29 Signed-off-by: Alex Ellis (OpenFaaS Ltd) <alexellis2@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The OpenFaaS API can offer CRUD (without the R) for secrets, these can then be mounted into OpenFaaS containers at deployment time.
It would be good to have some consistency here and match the other providers.
How will secrets be stored and mounted? Are we satisfied with the tradeoffs?
Environment variables:
Should people use environment variables, which are also available in plaintext to authenticated users who list functions? Easy to implement, no files on disk, but can find the value by inspecting the container
Flat files:
Not encrypted at rest, but Kubernetes doesn't do this either. May be stored where the basic auth secrets are generated?
The text was updated successfully, but these errors were encountered: