Secrets Store CSI Driver and the Azure Keyvault Provider

[savanipoojan78]

Why we need to run Secrets Store CSI Driver and the Azure Keyvault Provider in all the nodes?
and secrets-store-provider-azure in running 1 pod and secrets-store-csi-driver in running 3 pods in there specific reason of this number and how can i change this to run 1 pods for each of this.

[aramase]

The Secrets Store CSI Driver integrates external secrets store via a Container Storage Interface (CSI) volume. This means the CSI node plugin needs to be run on every node so that the kubelet process on the node can invoke the CSI driver for volume mounts on the node.

The driver is a pod with 3 containers - node-driver-registrar for registering the driver with kubelet, secrets-store which implements the actual driver and liveness-probe to perform periodic health check on the driver. The provider pod only has 1 container.

[ritazh]

@aramase might be good to add this to the concepts.md doc

[ovidiubuligan]

@aramase K8s secrets can already be mapped to files via the built in tempFs https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod . I think you can go without the need for all these extra components .
If you look at the following project it looks like it is a lot simpler : https://github.com/external-secrets/kubernetes-external-secrets .
My question is now , what can this project do that this one cannot https://github.com/external-secrets/kubernetes-external-secrets ?

[aramase]

@ovidiubuligan The Secrets Store CSI Driver provides a pluggable interface to support multiple providers. The permissions required to access the external secrets store (Azure Keyvault, Hashicorp Vault, Google Secret Manager or AWS Secrets Manager) is provided to the application pod or it's service account instead of to the controller pod. The CSI driver supports mounting the content in the pod volume tmpfs and optionally syncing the mounted content as k8s secret.