I'm facing an issue where our organizational policy doesn't permit running containers as root, but the CSI driver daemonset I'm working with defaults to running as root. I'm looking for ways to operate it under a non-root context. One solution I've considered is using External Secrets Operator (ESO), but I'm not sure about the implications since ESO stores secrets in etcd. I hesitate to go down that route. Another option I thought of is creating an init container to fetch secrets from AWS Secrets Manager and mount them as files in the pod. I'm relatively new to Kubernetes and would appreciate advice on how to effectively manage secrets in this environment. How do you handle your secrets?
4 Answers
Thanks for the feedback! I get the concern about complexity; I don’t want to complicate things too much either. It's reassuring to hear that ESO is trusted in real-world scenarios.
Using ESO combined with EKS Envelope Encryption (KMS) worked for us in the past. It’s a good solution if you're cautious about security while pulling secrets.
Storing secrets in etcd isn’t necessarily 'bad' unless someone has outright access to it, in which case you would have bigger security problems. ESO is definitely a solid choice! Just keep in mind that while pulling secrets directly from AWS Secrets Manager is the ideal method, since you’re using EKS, it’s good news that you don’t have direct access to etcd, which adds some layer of security.
If you're just starting with Kubernetes, it's wise to stick to established methods for critical things like secrets management. When I've implemented External Secrets Operator at various places, even in high-security environments like banks, it’s worked out really well. Just keep it straightforward and use trusted tools.
Related Questions
How To: Running Codex CLI on Windows with Azure OpenAI
Set Wordpress Featured Image Using Javascript
How To Fix PHP Random Being The Same
Why no WebP Support with Wordpress
Replace Wordpress Cron With Linux Cron
Customize Yoast Canonical URL Programmatically