Create kubernetes secret with few different keys from single secret in GCP secret manager

[sharipalik]

Describe the solution you'd like
My application has ENV variables which reference to kubernetes secrets and these kubernetes secret objects have few keys like this:

secret.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: db-secrets
type: Opaque
data:
  username: someusername
  password: somepassword

deployment.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  namespace: secret-store-test
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      serviceAccountName: some-service-account
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80
        env:
        - name: DB_USERNAME
          valueFrom:
            secretKeyRef:
              name: db-secrets
              key: username
        - name: DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: db-secrets
              key: password
      nodeSelector:
        iam.gke.io/gke-metadata-server-enabled: "true"

Now I'm trying to implement secret-store-csi-driver and GCP Secret Manager approach:

1. I installed CSI driver and GCP plugin for this

helm install csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver --namespace kube-system --set syncSecret.enabled=true --set enableSecretRotation=true --set rotationPollInterval="120s"

 helm upgrade --install secrets-store-csi-driver-provider-gcp charts/secrets-store-csi-driver-provider-gcp

2. My pods have access to GCP as I enabled workload identity
3. i created a simple secret test-dummy-secret in GCP Secret Manager which contains data:

username: "someusername"
password: "somepassword"

Now I need to create SecretProviderClass which creates kubernetes secret with 2 keys username and password from single secret in GCP Secret Manager. How can I implement this?

This is my SecretProviderClass object:

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: database-secret-provider
  namespace: secret-store-test
spec:
  provider: gcp
  parameters:
    secrets: |
      - resourceName: "projects/156372456417/secrets/test-dummy-secret/versions/1"
        fileName: "dbsecret"      
  secretObjects:
    - secretName: db-secrets
      type: Opaque
      data:
        - objectName: "dbsecret"
          key: username
        - objectName: "?????"
          key: password

Pods are deployed and secrets been created. Great!

The problem is it creates kubernetes secret with key username which contains all context of GCP test-dummy-secret
But I need to be able create single kubernetes secret with several keys from single GCP secret, rather then create a separate secret for each key. It's pretty hard to maintain when for each kubernetes secret key you have a separate secret in GCP secret manager

I also read this PR and couldn't understand how you defined objectName there. I mean how you create 2 different objectName from single file name

data:
        - objectName: foo
          key: username
        - objectName: foo1
          key: password
  parameters:
    auth: provider-adc
    secrets: |
      - resourceName: $RESOURCE_NAME
        fileName: $FILE_NAME

As I understand, to create kubernetes secret with different key values it should be like this?

data:
        - objectName: foo
          key: username
        - objectName: foo1
          key: password
  parameters:
    auth: provider-adc
    secrets: |
      - resourceName: "projects/17462856347/secrets/test-dummy-secret/versions/1"
        fileName: foo
      - resourceName: "projects/17462856347/secrets/test-dummy-secret-2/versions/1"
        fileName: foo1

Thanks!

Environment:

• Secrets Store CSI Driver version: (use the image tag):
• Kubernetes version: (use kubectl version):

[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

[k8s-triage-robot]

The Kubernetes project currently lacks enough active 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.