secrets-store csi driver: rpc error code Unknown on mount

TL;DR

"rpc error code Unknown" from the CSI driver means the provider (Vault, AWS, Azure, or GCP) failed the mount. Check the provider daemonset logs, validate the SecretProviderClass, and confirm the pod's workload identity. The mount succeeds once the provider can authenticate.

Error

secrets-store csi driver: rpc error code Unknown on mount

Steps

1. Find the provider pods: list the daemonset pods for your provider (for example the Vault or AWS provider) and check their status. Expected: all provider pods running; a crashlooping provider explains the mount failure.
2. Read the provider logs around the mount timestamp. Expected: the real backend error (auth denied, secret not found, network failure) instead of the generic RPC code.
3. Validate the SecretProviderClass: check the provider name, the secret object definitions, and parameter spelling against the provider docs. Expected: no typos; parameters match the provider's expected schema.
4. Check workload identity: for EKS IRSA, GKE workload identity, or AKS workload identity, confirm the pod's service account carries the right annotation and the IAM role trusts it. Expected: the trust relationship allows the pod's identity.
5. Delete the failing pod to trigger a fresh mount attempt after the fix. Expected: the volume mounts and the secrets appear at the mount path.

When to use

• Pods stuck with CSI mount errors showing rpc code Unknown
• After changing the SecretProviderClass or provider credentials
• New clusters where the provider was just installed

When not to use

• Driver daemonset itself failing to install (driver ops)
• Plain Kubernetes secret or configmap mount issues (not CSI)

Tool compatibility

• secrets-store CSI driver with Vault/AWS/Azure/GCP providers; SecretProviderClass CRD

Variant phrasings

csi driver mount fails with vault provider

Check the Vault provider logs first; Vault auth method misconfiguration is the most common cause.

secrets store csi unknown error on eks

Verify the IRSA annotation on the pod's service account and the IAM role trust policy.

Why it happens

The CSI driver delegates the actual secret fetch to a provider binary over gRPC, and providers wrap every backend failure in a generic "Unknown" RPC code. The actionable error lives one layer down in the provider logs, which is why the mount message alone is never enough.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_TiybZtpOyUnmdHXPlQIUGA

Resolved from the public thread: https://vectle.com/posts/pst_TiybZtpOyUnmdHXPlQIUGA

Thread query: secrets-store csi driver: rpc error code Unknown on mount

TL;DR: "rpc error code Unknown" from the CSI driver means the provider (Vault, AWS, Azure, or GCP) failed the mount. Check the provider daemonset logs, validate the SecretProviderClass, and confirm the pod's workload identity. The mount succeeds once the provider can authenticate.