Protecting Secrets in Kubernetes using the Fortanix CSI Provider

As organizations continue to adopt Kubernetes for orchestrating containerized workloads, one challenge consistently rises to the top: how to secure sensitive data such as secrets, certificates, and encryption keys in a dynamic, distributed environment.

In this blog, I’ll explain what the Secrets Store Container Storage Interface (CSI) Driver is and why integrating it with Fortanix Data Security Manager (DSM) offers a robust, scalable, and secure solution for managing and protecting secrets in Kubernetes.

What are the Secrets Store CSI Driver?

CSI, or Container Storage Interface, is a standardized interface that allows storage vendors to expose their storage systems to container orchestrators like Kubernetes. While traditionally used for persistent storage volumes, the Secrets Store CSI Driver allows Kubernetes pods to securely mount secrets, keys, and certificates as volumes, using external secret management systems.

A CSI Provider is a plugin to this Secrets Store interface, responsible for communicating with an external secrets store (like HashiCorp Vault, Azure Key Vault, AWS Secrets Manager… or in our case, Fortanix DSM).

This abstraction keeps secrets out of etcd, the internal Kubernetes key-value store, which isn't ideal for highly sensitive data unless encrypted properly.

Why Use Fortanix DSM as a CSI Provider?

Fortanix DSM is a modern, enterprise grade HSM (Hardware Security Module) backed solution, built to secure sensitive data across hybrid and multi cloud environments. It supports cryptographic operations, key management, secrets management, and more; all with FIPS 140 Level 3 security.

Here’s why using Fortanix DSM with Kubernetes through a CSI Provider makes perfect sense:

1. Hardware backed security

Unlike software-only secrets stores, Fortanix DSM provides HSM grade protection. That means secrets stored in Fortanix never leave the secure boundary unless explicitly requested, and all operations can be done in a cryptographically secure enclave.

2. Centralized secrets management

When using Fortanix DSM, you can manage all your keys, secrets, and certificates in a single place, with fine grained access controls and policy enforcement. This simplifies audits, rotations, and access reviews.

3. Improved compliance posture

By integrating Fortanix DSM with Kubernetes via CSI, your workloads benefit from an architecture that’s aligned with compliance standards like HIPAA, PCI-DSS, and GDPR, where strong cryptographic controls and key protection are mandatory.

4. No secrets stored in Kubernetes

Secrets don’t get persisted in Kubernetes etcd by default, they’re mounted directly into pods from Fortanix DSM and live in memory only as long as the pod exists. This reduces the attack surface and mitigates the risk of credential leakage from Kubernetes components.

Fortanix CSI Provider

To bridge Kubernetes and Fortanix DSM, Fortanix has built a CSI Provider that:

• Authenticates to Fortanix DSM using an API key or client credentials
• Retrieves secrets or keys based on the SecretProviderClass definitions
• Mounts them into pods as in memory volumes
• Optionally syncs them back into Kubernetes as Secrets (if needed)

This allows teams to transparently consume Fortanix-protected secrets inside Kubernetes pods without having to manually fetch, inject, or rotate them.

For more information :

Github - https://github.com/fortanix/fortanix-csi-provider

Support Document - https://support.fortanix.com