secrets-store-csi-driver VS Reloader

I'm not a fan of this approach. I think the Secrets Store CSI Driver (https://secrets-store-csi-driver.sigs.k8s.io/) has a better approach.

If you deploy on k8s, keep your eye on https://secrets-store-csi-driver.sigs.k8s.io/

Considering the major limitations of using Kubernetes Secrets, there are many new approaches being developed by the Kubernetes community. Kubernetes SIGs like the Secrets Store CSI Driver and solutions like the external secrets operator that works with third-party secret managers, and options to seal secrets through tools like bitnami’s sealed-secrets. To skip the tools and move directly to best practices, click here.

Just to clarify, CSI secret driver is from cncf not Microsoft. Only msft piece is the portion that integrates with key vault. https://secrets-store-csi-driver.sigs.k8s.io/

https://secrets-store-csi-driver.sigs.k8s.io/ and https://developer.hashicorp.com/vault/tutorials/kubernetes/kubernetes-secret-store-driver

The Secrets Store CSI Driver is a native upstream Kubernetes driver that can be used to abstract where the secret is stored from the workload. If you want to use a cloud provider's secret manager without exposing the secrets as Kubernetes Secret objects, you can use the CSI Driver to mount secrets as volumes in your pods. This is a great option if you use a cloud provider to host your Kubernetes cluster. The driver supports many cloud providers and can be used with different secret managers.

A relatively new and emerging method uses a Kubernetes Secrets Store CSI Driver, which allows secrets stored in secret managers to be mounted into pods as a volume. Once the Volume is attached to the Pod, the data is mounted into the container's file system.

The go k8s packages are pretty bloated - this may also just be a niche case. If you are looking to get secrets with hot reloading, you might also consider mounting a file or setting env vars and coupling it with this reloading operator: https://github.com/stakater/Reloader

For the auto restart this has been a staple install in all clusters for years for me: https://github.com/stakater/Reloader

Unfortunately, there isn't one out-of-the-box, elegant solution for triggering deployments to be reloaded with the solutions we've shown. You'd need to rely on open source tools such as Reloader, which watches for changes in ConfigMap and Secrets and does rolling upgrades on Pods with their associated Deployment, StatefulSet, DaemonSet, and DeploymentConfig.

It makes sense to use multiple containers for the same deployment, if they serve the same purpose, i.e. if there's a reloader present etc.

If you just need to restart pods, https://github.com/stakater/Reloader might be a good option. Anything more advanced will likely require a component that integrates with the Kube API.

E.g. on a cloud provider use their secrets management solution. Bring the secrets from git/sops into their store, then for the application use external-secrets to bring a copy into your namespace and update your deployments with reloader.

on top of that combine https://github.com/stakater/Reloader into the mix to bounce pods around when it detects a cm or secret that gets updated from upstream