OpenShift Secrets Store CSI Driver Operator - Privileges

gistfile1.md

The supported OpenShift Secrets Store CSI Driver Operator (available in OpenShift 4.14+) requires specific privileges to manage the lifecycle of the driver and its providers.

To understand the privileges, it's best to look at three distinct layers: the Operator, the Driver/Providers, and your Application Workloads.

1. The Operator Privileges

The operator itself runs in the openshift-cluster-csi-drivers namespace.

• Role: It acts as a controller that manages the deployment of the CSI driver (DaemonSet) and the required Custom Resource Definitions (CRDs).
• RBAC: It has cluster-wide permissions to manage ClusterCSIDriver objects, DaemonSets, ServiceAccounts, and the Secrets Store CRDs (SecretProviderClass and SecretProviderClassPodStatus).
• SCC: The operator pod itself typically runs with standard service account privileges, but it has the authority to deploy pods that are highly privileged.

2. The Driver & Provider Privileges (High Privilege)

This is where most of the sensitive permissions reside. Because the CSI driver must mount volumes directly into application pods on the host, it requires elevated access.

• Security Context Constraint (SCC): The CSI Driver DaemonSet (the node agent) and most Providers (AWS, Azure, GCP, Vault) must run as privileged.

• Why? * They need to perform mount/unmount operations on the host filesystem.

• They communicate with the Kubelet via Unix domain sockets.

• They often need to access host paths to store provider-specific binaries or sockets.

• Manual Step: For many providers (especially in Tech Preview or manual installs), you must explicitly grant the privileged SCC to the provider's service account:

oc adm policy add-scc-to-user privileged -z csi-secrets-store-provider-aws -n openshift-cluster-csi-drivers

3. Application Workload Privileges (Least Privilege)

One of the main benefits of this operator is that your application pods do not need high privileges to consume the secrets.

• SCC Requirement: By default, OpenShift’s restricted or restricted-v2 SCCs do not allow csi volume types.
• The Modern Way (OCP 4.13+): OpenShift uses a label on the CSIDriver object to allow restricted pods to use it without changing their SCC. The operator typically handles this, but you can verify it:

oc label csidriver/secrets-store.csi.k8s.io security.openshift.io/csi-ephemeral-volume-profile=restricted

• Permissions: Your app pod only needs GET permissions for the SecretProviderClass in its namespace. It does not need permissions to read Kubernetes Secrets unless you are using the "Sync as Kubernetes Secret" feature.

4. Comparison: Native Secrets vs. CSI Driver

Feature	Native K8s Secrets	Secrets Store CSI Driver
Storage	Stored in etcd (potentially plain text)	Stored in external Vault/KMS; ephemeral in-memory (tmpfs) on the node.
RBAC	Anyone with GET secrets can read them.	Access is gated by the external Provider's IAM/Policy and the SecretProviderClass.
Lifecycle	Persists until deleted.	Exists only as long as the pod is running.

Security Considerations for Your Setup

• Namespace Isolation: The operator and driver reside in openshift-cluster-csi-drivers. Do not grant users access to this namespace, as they could potentially manipulate the driver to intercept secret mounts.
• Rotation: If you enable Auto-Rotation, the driver will periodically re-fetch secrets from the external store. This requires the Driver/Provider pods to have long-lived or renewable credentials to the external vault.
• Audit Logs: Because the operator uses the SecretProviderClassPodStatus CRD, you can audit which pods are mounting which secrets and which versions they are using via standard OpenShift audit logs.

If you are concerned about the privileged requirement for the driver pods, it is a standard necessity for all CSI drivers in Kubernetes. The security boundary is maintained by ensuring that only the trusted driver runs as privileged, while your applications remain restricted.