secrets-store-csi-driver
Secrets Store CSI driver for Kubernetes secrets - Integrates secrets stores with Kubernetes via a CSI volume.
Top Related Projects
External Secrets Operator reads information from a third-party service like AWS Secrets Manager and automatically injects the values as Kubernetes Secrets.
A Kubernetes controller and tool for one-way encrypted Secrets
Quick Overview
The Secrets Store CSI Driver is a Kubernetes project that enables users to securely mount secrets, keys, and certificates from external secret stores into their pods as volumes. It supports various secret providers like Azure Key Vault, HashiCorp Vault, and AWS Secrets Manager, allowing for seamless integration of external secret management systems with Kubernetes applications.
Pros
- Enhances security by allowing applications to access secrets without storing them directly in Kubernetes
- Supports multiple secret providers, offering flexibility in secret management solutions
- Integrates well with existing Kubernetes infrastructure and practices
- Provides automatic secret rotation capabilities
Cons
- Adds complexity to the Kubernetes cluster setup and management
- Requires additional configuration and setup for each secret provider
- May introduce slight performance overhead due to external secret fetching
- Limited to supported secret providers; custom integrations may require additional development
Getting Started
To get started with the Secrets Store CSI Driver:
- Install the driver using Helm:
helm repo add secrets-store-csi-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts
helm install csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver --namespace kube-system
- Install the desired secret provider (e.g., Azure Key Vault):
helm repo add csi-secrets-store-provider-azure https://azure.github.io/secrets-store-csi-driver-provider-azure/charts
helm install azure-csi-provider csi-secrets-store-provider-azure/csi-secrets-store-provider-azure --namespace kube-system
- Create a SecretProviderClass resource to define the secrets to be mounted:
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: azure-kvname
spec:
provider: azure
parameters:
usePodIdentity: "false"
keyvaultName: "<your-key-vault-name>"
objects: |
array:
- |
objectName: secret1
objectType: secret
objectVersion: ""
tenantId: "<your-tenant-id>"
- Mount the secrets in your pod specification:
volumes:
- name: secrets-store-inline
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: "azure-kvname"
For more detailed instructions and provider-specific configurations, refer to the project's documentation.
Competitor Comparisons
External Secrets Operator reads information from a third-party service like AWS Secrets Manager and automatically injects the values as Kubernetes Secrets.
Pros of External Secrets
- Supports a wider range of secret backends, including cloud provider secret managers and third-party solutions
- Offers more flexibility in secret management with features like secret templating and automatic rotation
- Provides a unified API for managing secrets across different environments and clusters
Cons of External Secrets
- Requires additional setup and configuration compared to the simpler CSI driver approach
- May introduce latency in secret retrieval due to external API calls
- Potential security concerns with centralized secret management and increased attack surface
Code Comparison
Secrets Store CSI Driver (ConfigMap):
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: azure-kvname
spec:
provider: azure
parameters:
usePodIdentity: "true"
keyvaultName: "kvname"
External Secrets (ExternalSecret):
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: example
spec:
secretStoreRef:
name: secretstore-sample
kind: SecretStore
target:
name: example-secret
data:
- secretKey: username
remoteRef:
key: secret/data/mysecret
property: username
A Kubernetes controller and tool for one-way encrypted Secrets
Pros of Sealed Secrets
- Encrypts secrets at rest, allowing safe storage in version control
- Doesn't require external services or infrastructure
- Lightweight and easy to set up
Cons of Sealed Secrets
- Limited to Kubernetes native secrets
- Doesn't support dynamic secret rotation
- Lacks integration with external secret management systems
Code Comparison
Sealed Secrets:
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
name: mysecret
spec:
encryptedData:
password: AgBy3i4OJSWK+PiTySYZZA==
Secrets Store CSI Driver:
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: azure-kvname
spec:
provider: azure
parameters:
usePodIdentity: "true"
keyvaultName: "kvname"
objects: |
array:
- |
objectName: secret1
objectType: secret
objectVersion: ""
The Secrets Store CSI Driver allows for more flexible integration with external secret management systems, while Sealed Secrets focuses on encrypting Kubernetes native secrets. The CSI Driver supports various providers and dynamic secret rotation, whereas Sealed Secrets offers a simpler, self-contained solution for encrypting secrets at rest.
Convert 
designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Kubernetes Secrets Store CSI Driver
Secrets Store CSI Driver for Kubernetes secrets - Integrates secrets stores with Kubernetes via a Container Storage Interface (CSI) volume. The Secrets Store CSI Driver is a subproject of Kubernetes SIG Auth.
The Secrets Store CSI Driver secrets-store.csi.k8s.io allows Kubernetes to mount multiple secrets, keys, and certs stored in enterprise-grade external secrets stores into their pods as a volume. Once the Volume is attached, the data in it is mounted into the container's file system.
Test Status
| Test | Status |
|---|---|
| periodic/image-scan | |
| periodic/e2e-provider-upgrade | |
| postsubmit/aws | |
| postsubmit/azure | |
| postsubmit/gcp | |
| postsubmit/vault |
Want to help?
Join us to help define the direction and implementation of this project!
- Join the #csi-secrets-store channel on Kubernetes Slack.
- Join the Mailing list to receive notifications for releases, security announcements, etc.
- Use GitHub Issues to file bugs, request features, or ask questions asynchronously.
- Join biweekly community meetings to discuss development, issues, use cases, etc.
Features
- Mounts secrets/keys/certs to pod using a CSI Inline volume
- Supports mounting multiple secrets store objects as a single volume
- Supports multiple secrets stores as providers. Multiple providers can run in the same cluster simultaneously.
- Supports pod portability with the SecretProviderClass CRD
- Supports Linux and Windows containers
- Supports sync with Kubernetes Secrets
Demo
Getting Started
Check out the installation instructions to deploy the Secrets Store CSI Driver and providers. Get familiar with our CRDs and core components
Development Guide
Follow these steps to setup Secrets Store CSI Driver for local debugging.
Documentation
Please see the docs for more in-depth information and supported features.
Getting involved and contributing
Are you interested in contributing to secrets-store-csi-driver? We, the maintainers and community, would love your suggestions, contributions, and help! Also, the maintainers can be contacted at any time to learn more about how to get involved.
In the interest of getting more new people involved, we tag issues with good first issue. These are typically issues that have smaller scope but are good ways to start to get acquainted with the codebase.
We also encourage ALL active community participants to act as if they are maintainers, even if you don't have "official" write permissions. This is a community effort, we are here to serve the Kubernetes community. If you have an active interest and you want to get involved, you have real power! Don't assume that the only people who can get things done around here are the "maintainers".
We also would love to add more "official" maintainers, so show us what you can do!
Check out Secrets Store CSI Driver Membership for more information.
Code of conduct
Participation in the Kubernetes community is governed by the Kubernetes Code of Conduct.
Top Related Projects
External Secrets Operator reads information from a third-party service like AWS Secrets Manager and automatically injects the values as Kubernetes Secrets.
A Kubernetes controller and tool for one-way encrypted Secrets
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot