How to mount secrets in SecretProviderClass as Env Vars in a Pod

[vidocco]

Question

Hi! We're trying to use the gcp provider for secret store to mount some secrets as environment variables in a pod. Checking the example provided in the repo, it only shows how to mount them as volumes.

We've been following this example to try and set them as environment variables but it seems like the "parameters" option changes depending on the provider: is there a way of achieving this with the gcp provider currently?

[tam7t]

#37 (comment) has an example that should work.

The parameters fields of the SecretProviderClass are going to be unique to each individual provider but the part that controls secret syncing to k8s is common among all providers:

...
  secretObjects:
  - secretName: foosecret
    type: Opaque
    data: 
    - objectName: good1.txt
      key: pwd
...

For this objectName must match the fileName (or path) GCP parameter.

This would create a K8s secret named foosecret with a key of pwd where the value is the contents of the good1.txt file. From there you can reference the k8s secret for envvars as you would any other k8s secret.

[vidocco]

Thanks, that helped! I think an example of how to do this and some documentation would really help (also, maybe the key fileName makes things a bit more confusing than they should be but I understand changing it now wouldn't be ideal).

[idanya]

Hi,
I'm experiencing an issue trying to sync a GCP secret as a k8s one.
Using the same method without the mapping to a k8s object works well and I can mount secrets as files on the pod's filesystem.
Trying to create the secret object so I can use the value as ENV (my understanding is that I have to do this kind of mapping in order for the value to be available as ENV) doesn't work. The secret is not being created and no visible errors in the driver pods.

Installed via Helm with sync enabled and verified the secretprovidersyncing-role object present and bound to the driver service account.

Secret:

apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: <secret-name>
  namespace: <namespace>
spec:
  provider: gcp
  parameters:
    secrets: |
      - resourceName: "projects/.../secrets/<secret-name-in-secret-manager>/versions/latest"
        fileName: "secret.data"
  secretObjects:
    - secretName: <k8s-secret-name>
      type: Opaque
      data: 
      - objectName: secret.data
        key: <key in k8s object>

Pod:

spec:
  - name: SECRET
      valueFrom:
        secretKeyRef:
          name: <k8s-secret-name>
          key: <key in k8s object>

[anu1508k]

@idanya : I am facing the exact same issue as yours. No logs in the driver pods. Is your issue resolved?

[idanya]

It was a long time ago, but if I remember correctly, you have to mount it to the file system in order to trigger the driver, and only then it will work.

[hconnan]

Any update? I am currently facing the exact same issue, no logs that can help me to understand why a k8s secret is not created.
Maybe I am missing something in the configuration.

Any detail you forgot to mention @tam7t?

[ebuildy]

hey @idanya did you add the volume part as well?

SecretProviderClass will not create a secret it-self.

[amitmodak]

Here's a good example that may help: https://github.com/GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp/blob/main/test/e2e/templates/test-sync.yaml.tmpl (please replace $TEST_SECRET_ID and $PROJECT_ID as appropriate).

Also, please ensure that the "Sync as Kubernetes Secret" feature is enabled on the driver: https://secrets-store-csi-driver.sigs.k8s.io/getting-started/installation.html#optional-values

[tcolgate]

As per @idanya's suggestion, you need to

• enable secret sync in the secrets-store-csi driver
• make sure the pod mounts the provider class as a volume
• then you can use envFrom and env.valueFrom the secret you have setup in the provider class

You need the mount, even though the pod may not use it, without this the driver wont provision the secret.

In theory, secrets-store-csi-driver /could/ note which secrets are used by which provider classes, and then check if they are in use by new pods, rather than just check the volumes.

[amitmodak]

Thanks for reporting this issue! There does not seem to be any further action item on this issue and hence we are closing it. Please feel free to reopen this issue or file a new one if you need further assistance.