@Moritz Johner - just finished your talk, first of all thanks for this awesome open source project and the time you and the other contributor put into it. I really like the idea of having a component abstracting away the different implementation quirks of the many secret management solutions out there. In our use case we are currently mainly connecting to HashiCorp Vault and using their agent injector (basically and admission web hook that adds a Vault agent to desired pods) in order to interact with our Vault clusters. One thing in particular that this solution enables us to do is the injection of external secrets as environment variables in Kubernetes without the need to persist them anywhere on the Kubernetes side (not in files, on the control-plane e.g. via Secrets nor in the pods ephemeral storage) - just an example for reference: https://www.vaultproject.io/docs/platform/k8s/injector/examples#environment-variable-example. From a security standpoint the secrets therefore are only stored in the memory segment of the pod where they would ultimately always end up if the application reads them in from any other source. Is such a "memory only" approach something that is possible to achieve with EOS? Or something that might be on the future roadmap?

thanks @Daniel Haß for your kind words ❤️. This is a very good point that you're making around security (more on that below).

Is such a "memory only" approach something that is possible to achieve with EOS? Or something that might be on the future roadmap?

tl;dr: no, this isn't planned/intended. This is where the Secret Store CSI driver (or sidecar-injector) should be used if that is your requirement. ESO is built around the

Kind=Secret

resource as this is the generic way of using Secrets within Kubernetes: e.g. TLS certs for

Kind=Ingress

, ImagePullSecrets etc. With your approach (agent-injector), but also when using CSI secret store your rely heavily on HashiCorp Vault being available. If it is not available you're not able to start a Pod. ESO allows you to use Kubernetes Secrets as an additional caching/pull-through layer for secrets so that you won't be impacted when Vault is not available. Pods can still start and do their work. That - sorts of - contradicts the Secret Sprawl and fragmentation argument, but this is a trade-off that you can make to alleviate the availability issue. Regarding security / Sidenote: I've had a lot of discussions whether it is acceptable to store credentials in Kubernetes as

Kind=Secret

(vs. in-memory access) or not. And it really depends on your threat model in your context. I found this article very helpful for developing a threat model: https://www.macchaffee.com/blog/2022/k8s-secrets/

@Moritz Johner thanks for your fast and detailed answer. I totally get your focus on the Kubernetes Secret resource. And also the dependency to Vault your are mentioning is totally reasonable. EOS (at least from a Secrets perspective) creates a self-contained cluster, although with the premise that the external secrets do not get rotated during the time frame where something goes wrong and EOS isn't able to update the secrets for whatever reason. Thanks for sharing the article written by Mac. Although its getting a little "rant'y" at the end towards Vault it think its still a great eye-opener towards that fact that you need a thread model in order to discuss security things (and that etcd encryption is not the holy grail to solve this).