Get all k/v pairs from endpoint

[dirtycajunrice]

Motivation
Some applications require a significant amount of configuration that is sensitive. This becomes extremely tedious and adds redundancy and toil where it could be reduced using the same functionality that envFrom uses in kubernetes core as well as established solutions like external-secrets

Describe the solution you'd like
2 Separate requests.

1. Make secretKey optional. If the user has no intention of renaming the secret key, nor specifying a GET request solely for that key, it is redundant declarations that add up.
2. Allow all keys to be ingested from an endpoint.

A practical example with only 5 k/v pairs currently looks like:

apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: my-secret
  namespace: default
spec:
  provider: vault
  parameters:
    roleName: "csi-secrets-store"
    vaultAddress: https://vault.company.tld
    vaultKubernetesMountPath: kubernetes/eks-use1-sre-prod
    objects: |
      - objectName: PG_DB_PASSWORD
        secretKey: PG_DB_PASSWORD
        secretPath: kv-v2/data/my-app
      - objectName: APP_TOKEN
        secretKey: APP_TOKEN
        secretPath: kv-v2/data/my-app
      - objectName: OAUTH_CLIENT_ID
        secretKey: OAUTH_CLIENT_ID
        secretPath: kv-v2/data/my-app
      - objectName: OAUTH_SECRET
        secretKey: OAUTH_SECRET
        secretPath: kv-v2/data/my-app
      - objectName: SMTP_PASSWORD
        secretKey: SMTP_PASSWORD
        secretPath: kv-v2/data/my-app
  secretObjects:
    - type: Opaque
      secretName: my-app
      data:
        - key: PG_DB_PASSWORD
          objectName: PG_DB_PASSWORD
        - key: APP_TOKEN
          objectName: APP_TOKEN
        - key: OAUTH_CLIENT_ID
          objectName: OAUTH_CLIENT_ID
        - key: OAUTH_SECRET
          objectName: OAUTH_SECRET
        - key: SMTP_PASSWORD
          objectName: SMTP_PASSWORD

When all you should really need is

apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: my-secret
  namespace: default
spec:
  provider: vault
  parameters:
    roleName: "csi-secrets-store"
    vaultAddress: https://vault.company.tld
    vaultKubernetesMountPath: kubernetes/eks-use1-sre-prod
    objectListFrom: 
      - name: my-app-keys
        secretPath: kv-v2/data/my-app
  secretObjects:
    - type: Opaque
      secretName: my-app
      dataFrom:
        - objectList: my-app-keys

[tam7t]

Everything within parameters on a SecretProviderClass is opaque to the driver and interpreted by the individual providers. I think it may be good for providers to evaluate the feasibility of this with their respective APIs. I think I see similar issues open for AWS and Azure at this point:

• Add use of wildcard or prefix in objectName to get all matched parameters aws/secrets-store-csi-driver-provider-aws#9
• Mount Objects/Sync Secrets By Regex Pattern From Key Vault Azure/secrets-store-csi-driver-provider-azure#357

If there are commonalities between the solutions then we can investigate feasibility of a shared feature of the driver itself.

[dirtycajunrice]

@tam7t I completely understand that perspective. the secretObjects are part of the driver itself though correct? If an option is not available from the driver like "accept an array/list as an object", passed along from the providers, then they will not implement it as it would "go nowhere" right? Thoughts?

[tam7t]

Ah yes, secretObjects is defined by the driver and used for the K8s sync feature to map relative file paths to secret key/values - so changes to allow mapping multiple file paths to keys would require driver changes.

[manedurphy]

/assign

[ritazh]

+1

Looking forward to the detailed design doc so we can discuss some of the nuances this feature may bring.

Specifically, today with the secretObjects as a static list in SPC CR, this controller loops thru secretsObjects and creates secrets with the content in the mounted volume retrieved by the provider from the external secrets stores. There is an assumption that the object (file) exists in the mount, otherwise it will return an error and the reconciler will retry. So if that assumption is no longer valid, how does that controller know when a file doesn't exist is intentional or it should retry the reconcile loop.

With this feature request/proposal, the list of objects is maintained outside of the SPC CR via objectListfrom which makes it harder for the provider to validate if the right object actually exists in the external source or if it has the right permission to access that object. As a result, it makes error handling harder as the mount would succeed and application may fail silently. I think there are things we can add to make sure this is addressed. Let's discuss this more in the design doc.

[jacobbeasley]

Perhaps not directly related, but I wonder if inspiration could be drawn from the Vault Injector Sidecar's options, such as in the use of template files to extract and format a vault secret into a format that most applications can use natively (such as a .env file or a bash script with exported env vars).

https://www.vaultproject.io/docs/platform/k8s/injector#secret-templates

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[aramase]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[aramase]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[nilekhc]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages issues and PRs 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 or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[aramase]

/remove-lifecycle stale

[agates4]

/remove-lifecycle stale

[joebowbeer]

Has it been decided if this is entirely up to the providers to implement, or if changes are needed in this repo first?

Provider feature requests:

• AWS
  • Add use of wildcard or prefix in objectName to get all matched parameters aws/secrets-store-csi-driver-provider-aws#9
  • Sync all key/value pairs from AWS secret to K8S secret aws/secrets-store-csi-driver-provider-aws#46
• Azure
  • Mount Objects/Sync Secrets By Regex Pattern From Key Vault Azure/secrets-store-csi-driver-provider-azure#357
• GCP
  • Retrieve list of secrets with only one ResourceName GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp#181
• Vault
  • How to get all secrets in a file hashicorp/vault-csi-provider#114
  • Implicit mapping of secrets / objects - SecretProviderClass hashicorp/vault-csi-provider#192

[msitworld]

Hi, is there any update regarding this suggested feature?

[odarriba]

Is there any update on this issue? It would really help for deployments made using reutilizable code to create common K8s entities (namespaces, secrets stores, etc).

The workaround is currently a bit hacky (at least using AWS driver)

[zarcen]

Would like to bump this issue as it would be a really great feature to have

[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

[pierluigilenoci]

/remove-lifecycle stale

[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

[pierluigilenoci]

/remove-lifecycle stale

[sbaugh-rh]

Bump. This would be epic.

[allanian]

+1

[agates4]

+10

[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

[joebowbeer]

@manedurphy Is there any update to report?

[Jonnymcc]

This sounds trivial to implement. Currently using this to create ENV vars I get one var with a JSON value with all the k/v. Couldn't there be a flag on secretObjects that just takes the JSON and parses that when generating the secret? Or make data.key optional and provide the same behavior if no key is specified?

[joebowbeer]

I think this RFE is different than parsing JSON-valued secrets. In fact it probably shouldn't be parsing JSON-valued secrets IIUC...

This is about recursing a path and populating one secret with the data there under:

• foo.bar=xyz
• foo.zap.one=abc
• foo.zap.two="{ def: 1 }"

From path:

foo/
    bar=xyz
    zap/
        one=abc
        two="{ def: 1 }"

The "join" character "." that joins the keys should be configurable because "." is probably a legal character in a path segment.

[Jonnymcc]

@dirtycajunrice let us know if this is what you had in mind. Jonnymcc@a67e78e

Using the AWS provider, this takes a SSM secret with a value made up of k/v and creates a k8s secret where the k/v under data: match those stored in the SSM secret.

How it works: specify a secretObjects.data item without a key and it will parse the value stored in objectName as JSON.

[dirtycajunrice]

@Jonnymcc holy moly man its been 3 years, and i don't know what i had in mind for dinner last week 🤣. If i think really hard about it with the context i gave above...

I would not expect nesting/recursion. That adds adds complexity that although may have been inferred throughout the comments over the years, would not constitute an MVP. The MVP would simply call the /list endpoint of <provider> and inject every key/value pair returned. Most /list endpoints do not recurse.

An enhancement post-MVP of recursion may be beneficial, but we are 3 years of zero movement, so I would suggest making the target as scoped as possible to alleviate further "analysis paralysis"

[joebowbeer]

@dirtycajunrice This issue is referenced by a similar issue(s) in each provider implementation:

#529 (comment)

Provider feature requests:

• AWS
  • Add use of wildcard or prefix in objectName to get all matched parameters aws/secrets-store-csi-driver-provider-aws#9
  • Sync all key/value pairs from AWS secret to K8S secret aws/secrets-store-csi-driver-provider-aws#46
• Azure
  • Mount Objects/Sync Secrets By Regex Pattern From Key Vault Azure/secrets-store-csi-driver-provider-azure#357
• GCP
  • Retrieve list of secrets with only one ResourceName GoogleCloudPlatform/secrets-store-csi-driver-provider-gcp#181
• Vault
  • How to get all secrets in a file hashicorp/vault-csi-provider#114
  • Implicit mapping of secrets / objects - SecretProviderClass hashicorp/vault-csi-provider#192

In each case, the provider's native ability to fetch multiple secrets at once is not exposed through the SCSP API.

Progress is stalled and it appears to me that the change needs to happen here in the SCSP API.

External Secrets Operator (ESO) does provide this ability cross-platform. What I described above is essentially how ESO solves the problem:

https://external-secrets.io/latest/guides/getallsecrets/

Given the ESO implementation, I don't think there's a problem with analysis paralysis. I think the problem has been one of deciding whether its an issue for this component or for each provider.

Should I create a new issue to capture my interpretation or are you willing to let this issue stand as the meta issue that all the provider's issues point to?