Allow placing synced secrets directly in the data key

[eherot]

Describe the solution you'd like

First, to summarize The Problem
Right now the structure of a secretObject (docs|source) forces you (as far as I could tell, anyway) to load the contents of your secret into a subkey of the data key. This is an unfortunate limitation because the Kubernetes envFrom.secretRef function does not support loading from a subKey.

What I wanted to be able to do:
My AWS Secrets Manager secret:

ENVVAR1=value1
ENVVAR2=value2

My SecretProviderClass:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: my-secret-provider-class
spec:
  provider: aws
  secretObjects:
    - secretName: path-to-aws-secret
      type: Opaque
      data:
      - objectName: path-to-aws-secret
        key: envVars  # Would love to be able to leave this out!
  parameters:
    objects: |
      - objectName: /path/to/aws/secret
        objectType: "secretsmanager"
        objectAlias: path-to-aws-secret

For posterity, the relevant parts of my Deployment:

# ...
spec:
  template:
    spec:
      containers:
        envFrom:
          - secretRef:
              name: path-to-aws-secret
        volumeMounts:
            - name: secret-store-volume
              mountPath: /mnt/secret-store-volume
      volumes:
        - name: secret-store-volume
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: my-secret-provider-class

Expectation:

# In my container
$ echo $ENVVAR1
value1
$ echo $ENVVAR2
value2

Reality:

$ echo $ENVVAR1
$ echo $ENVVAR2
$ echo $envVars
ENVVAR1=value1
ENVVAR2=value2

Environment:

• Secrets Store CSI Driver version: (use the image tag): v1.3.1
• Kubernetes version: (use kubectl version): 1.23 (but AFAIK this limitation still exists on 1.26)

[estiscael]

is any way to achieve what is described in request?

[eherot]

Not that I've found in terms of a workaround but the fix in the code does look fairly straighforward at first glance...

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[eherot]

/remove-lifecycle stale

…

On Jan 19, 2024 at 4:00 AM -0500, Kubernetes Triage Robot ***@***.***>, wrote: The Kubernetes project currently lacks enough contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: • After 90d of inactivity, lifecycle/stale is applied • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed You can: • Mark this issue as fresh with /remove-lifecycle stale • Close this issue with /close • Offer to help out with Issue Triage Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[krzysztofantczak]

Really? no interest in this? This is really surprising to me. Because re-mapping all secret keys ie. when taken from secretmanager or whatever store manually key by key is just insane :D

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale