Infisical Provider for Secrets Store CSI Driver
Infisical provider for the Secrets Store CSI driver will allow you to mount Infisical secrets directly into your Kubernetes pods while maintaining secret-zero in your Kubernetes cluster.
Installation
Prerequisites
Using helm (Recommended)
helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts'
helm repo update
helm install infisical-csi-provider infisical-helm-charts/infisical-csi-provider
Using yaml
You can also install using the deployment config in the deployment folder:
kubectl apply -f deployment/infisical-csi-provider.deployment.yaml
Usage
For guidance, refer to the official documentation here.
Bounding how long secrets stay readable
By default a mounted secret stays readable for the pod's whole life, which hands the same access to
anything that later achieves code execution inside it. Setting windowDuration serves the secrets
only while the containers are freshly started, which is when the application actually needs them.
parameters:
windowDuration: "5m"
Once the window closes, the provider serves empty files and stops calling Infisical altogether: the
secret never leaves the platform, rather than being fetched and then withheld. The driver writes back
whatever payload the provider returns, which is what blanks the file. When a container restarts, the
window reopens, because a restarted container gets a fresh start time and needs its secrets again,
and the kubelet replays nothing on its behalf.
The window is evaluated from the pod's own status in the API server, which the pod cannot forge, so the
provider needs to read pods. Set readWindow.enabled=true on the chart to grant that and to scope the
watch to each node; the permission is not granted otherwise, since most installs will not use this.
Things this needs to work, and things it does not do:
- Rotation must be enabled on the driver, with
--enable-secret-rotation=true and a short
--rotation-poll-interval. The provider is otherwise only called at mount time and nothing ever
closes. The file blanks up to one poll interval after the window ends, and refills up to one
interval after a restart, so applications should retry their first read.
- It is incompatible with
secretObjects. The driver syncs mounted contents into a
namespace-scoped Kubernetes Secret independently of the window, so closing one pod's window writes
empty values into a Secret that other workloads may read. A per-pod exposure window cannot be
expressed through a cluster-wide object, and the provider cannot detect the conflict itself:
spec.secretObjects is not part of spec.parameters, which is all it receives.
- The window must be comfortably longer than it takes a grant to become usable. Against a
self-hosted instance, permission changes took about 11 seconds to take effect, which is why one
minute is too tight and five is the suggested starting point.
- A volume is the unit of enforcement, a container is the unit of decision. There is one file for
every container mounting the volume, so if two of them mount it, either one restarting refills the
file for both, and a long-running container regains access when its neighbour crashes. A tight window
wants exactly one consumer per volume.
- Nothing protects the secret during the window. Code running in the pod while it is open reads
the file. What this removes is the standing ability to read it for hours or days afterwards.
Leaving windowDuration unset keeps the previous behaviour.
Troubleshooting
To troubleshoot issues with the Infisical CSI provider, refer to the logs of the Infisical CSI provider running on the same node as your pod.
kubectl logs infisical-csi-provider-7x44t
You can also refer to the logs of the secrets store CSI driver. Modify the command below with the appropriate pod and namespace of your secrets store CSI driver installation.
kubectl logs csi-secrets-store-csi-driver-7h4jp -n=kube-system