Platform engineering is the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era.

Platform Engineering

thanks <@U03JX7XTL9G> for your kind words :heart:. This is a very good point that you're making around security (more on that below).
&gt; 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/>

<@U03FP77JR08> 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).