OpenShift CSI Driver for Secret Stores
RedHat OpenShift is introducing Secret Store CSI Operator as TechPreview in order to address these issues. Through a provider plugin, OpenShift users can mount secrets from external secret management systems such as AWS Secrets Manager or Azure Key Vault using the Secret Store CSI (SSCSI) driver. Applications can use the secrets, but once the application pod is destroyed, the secrets are no longer stored on the system. This allows the customers to have total control over how secrets are managed and stored by utilizing external to the cluster centralized secret storage. To secure and manage secrets, these external secret management solutions offer much stricter encryption options and access controls.
Among the salient characteristics are:
- Mounts certificates, keys, and secrets to a pod with a CSI Inline volume
- Encourages the mounting of numerous secrets assemble items into a single volume.
- accepts several secret stores as suppliers. It is possible for several providers to operate concurrently in one cluster.
- incorporates the SecretProviderClass CRD to enable pod portability.
- accommodates Windows and Linux containers
- synchronizes with Kubernetes Secrets support
The SSCSI driver, SSCSI provider, and any external secret source that the provider is connected to operate as follows in the secrets workflow:
- On a node, a pod is created and scheduled.
- To mount the volume, Kubelet sends a grpc request to the CSI driver.
- The process of volume mounting to the pod as tmpfs is initiated by the Secret Store CSI driver.
- After that, the SSCSI driver contacts the SSCSI provider with a GRC.
- Using the pod’s identity—which may be either a service account token for a pod or a temporary identity token—the SSCSI provider will communicate with the Secret Store.
- It returns content to the SSCSI driver as a gRPC response after retrieving the secrets.
- Driver adds the filesystem secret.
- Volume has been successfully installed in the pod as tmpfs.
- If the pod is deleted as part of the cleanup, the volume is eliminated.
User Situations
Using the SSCSI driver on the OpenShift platform has numerous applications that improve security and expedite compliance and operations, such as:
- A centralized secret management system that satisfies the organization’s regulatory requirements is what compliance managers would like to see all application secrets kept in. This makes problems easier to fix and lessens the impact of possible threats.
- Cluster administrators want to minimize overhead by enabling applications to retrieve secrets from the external provider and use the current secret management processes.
- In order to update secrets automatically and without the need for human intervention, application developers want their applications to automatically retrieve secrets from supported secret stores.
Installing the CSI driver operator for the Secret Store
Installing the Secret Store CSI Driver Operator from the Operator Hub is possible, and it is overseen by OLM. Make sure “Openshift-cluster-csi-drivers” is the install namespace and that “All namespaces on the cluster” is selected during the installation process. Add the following yaml to the instances tab for a driver cluster instance:
For more information, see our documentation. Volume provisioning is not necessary because, as was already mentioned, the SSCSI Driver only mounts secrets into ephemeral volumes, which are deleted along with the pod.
CRDs with CSI Driver from Secret Store
A SecretProviderClassPodStatus resource is created in the same namespace as the pod by the Secrets Store CSI Driver Operator. Review this resource to learn more about the secrets in the pod volume mount in detail, including versions.
The CSI driver receives driver configurations and provider-specific parameters from the SecretProviderClass custom resource. Below is an illustration using Azure Key Vault:
Secret Store CSI Driver Operator Features
The operator automatically activates two of the optional features:
Covert Auto Rotation
Content from the external secrets store is periodically rotated with content from the mounted volume by the Secrets Store CSI Driver. A secret will be updated in the mounted volume if it is modified in the external secrets store. Every two minutes, the CSI Driver Operator at the Secrets Store polls for updates. The Kubernetes secrets rotate as well if sync secrets are enabled. Applications that use the secret data have to keep an eye out for changes to the secrets.
Keep in mind that the secret updates are not propagated on rotation if you use a subPath volume mount. This restriction is well-known (see details here).
As Kubernetes Secret, Sync
Sync secrets enables you to use the content on the mounted volume to create Kubernetes secrets. If you want to use an environment variable in your deployment to reference the Kubernetes secret, for instance, you might want to enable synchronization.
Here’s an example of how to update the SecretProviderClass CRD with the Kubernetes secret data:
Gazing Forward
We work hard to protect your privacy! RedHat OpenShift hopes to offer a vendor-neutral solution with the Secret Store CSI Driver solution that can interface with secret storage systems that customers use to securely manage application secrets, such as Vault, AWS Secrets store, AWS Parameter store, and Azure Key Vault. Working with external secret providers is necessary for the end-to-end solution, so please let us know which ones you use and how we can support them going forward. We intend to closely monitor the feature sets of this solution as they are developed by upstream and collaborate with our network of partners to offer integrations for end-to-end solutions.
