Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
Moby
The Moby Project - a collaborative project for the container ecosystem to assemble container-based systems
For anyone new to SOPS like I was - https://github.com/getsops/sops
> If you want secure config storage on Kubernetes, you end up using Secrets, which ends up being key-value like env vars anyway.
You can load the secret file directly into the app, no need to load it as env vars or keep it strictly as key-value pairs.
> If you want similar security with Git you need a layer of encryption, which breaks diffs and requires additional tooling. This all leads back to why high-level deployment tools like Heroku were created.
You can use tools like ejson[1] or sops[2] to get encrypted files checked into Git that have key level granularity on diffs.
There is definitely a place for higher level abstractions than Kubernetes. Mostly it gives operators a standard platform to build from when teams outgrow the PaaS sandbox.
[1] https://github.com/Shopify/ejson
Hard agree. I think it's easy to get stuck on the mental model that "the configuration value is the secret" (which means the configuration itself needs special handling), and the correct mental model should be "the configuration value is the identifier of the secret", with another system (Azure Key Vault, etc) being responsible for converting the secret-identifier into the secret-value.
My company open sourced the .NET library we use for this: https://github.com/Lokad/Secrets
AppArmor can restrict /proc and this is even used by docker: https://github.com/moby/moby/blob/master/contrib/apparmor/te...