Daniel Haß06/10/2022, 9:31 AM
Moritz Johner06/10/2022, 9:55 AM
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
resource as this is the generic way of using Secrets within Kubernetes: e.g. TLS certs for
, 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
(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/
Daniel Haß06/10/2022, 10:12 AM