search

vapor-ware / sctl

SCTL is not End2End encryption, instead SCTL is more of an envelope, in which you store secrets until they are needed, and those secrets should only remain available in plain text while the operation that needs them is active.
GNU General Public License v3.0
8 stars 2 forks source link

ENV is great, but what about multi-line secrets? #4

Closed lazypower closed 5 years ago

lazypower commented 5 years ago

There are some manifests that we apply directly to kube. There's no clean way to utilize sctl to aid in this secret workflow.

Should there be an alternate injection method? Should sctl grow the ability to interpret gotemplates on the fly and provide resident in-place output vs the env guard?

Food for thought in upcoming iterations. I haven't fully mapped the pros/cons to this and what the implications are.

lazypower commented 5 years ago

we're going to need to base64 encode the contents before attempting to encrypt, and rely on double base64 encoded values.

This means we'll need to impose a breaking change, add a command to migrate, and default to the new behavior moving forward. I guess we could do some detection like IsBase64Encoded(*).. but i'm not sure its desireable to retain the current behavior which mangles multi-line content.

lazypower commented 5 years ago

Good news, no breaking changes, and no migration path needed.

lazypower commented 5 years ago

https://github.com/vapor-ware/sctl/releases -

Scuttle 0.8.2 is out. It retains backwards compatibility with our existing .scuttle.json state, and introduces new behavior that supports multi-line secrets by declaring encoding.

You can now env inject things like TLS certificates, PGP Keys, and configuration files for cloud providers. Additionally, if you encounter a situation where you want to encrypt base64 encoded data, that can be achieved now with the --no-decode flag when you sctl add a secret. Otherwise scuttle will decode the data and may mangle your value.