Secret Provider Class not support secretObject type stringData

[tamanh123456]

Describe the solution you'd like I deploy Drupal on Azure Kubernetes Service and mount key vault (key vault store database configuration). And drupal source has a option get environment variables by .env file. But csi mount secret not like my expect

Anything else you would like to add:

I expect the Secretproviderclass has more option to create secret like stringData type

k8s secret I expect secretproviderclass will create

kind: Secret
apiVersion: v1
metadata:
  name: environment-secret
type: Opaque
stringData:
  .env: |-
    db_host=my-db.host
    db_user=db-user
    db_password=db-pass

secretproviderclass config I expect

secretObjects:
- secretName: environment-secret
  type: Opaque
  stringData:
    .env: |-
      db_host=my-db.host
      db_user=db-user
      db_password=db-pass

Environment:

• Secrets Store CSI Driver helm version: (use the image tag): 1.0.1
• Kubernetes version: (use kubectl version): v1.21.9

[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

[anubisg1]

i fully agree, this is a big limitation which isn't either documented .. i hope this can be handled

[WilliamsDL]

Is there a way around this issue? If I store my secret as base64 encoded in AWS Secrets Manager, it is getting base64 encoded AGAIN when the secret is created. How do I prevent this?

[enj]

I do not see how this would work.

Per the docs:

	// stringData allows specifying non-binary secret data in string form.
	// It is provided as a write-only input field for convenience.
	// All keys and values are merged into the data field on write, overwriting any existing values.
	// The stringData field is never output when reading from the API.
	// +k8s:conversion-gen=false
	// +optional
	StringData map[string]string `json:"stringData,omitempty" protobuf:"bytes,4,rep,name=stringData"`

The important bits are:

It is provided as a write-only input field for convenience. ... The stringData field is never output when reading from the API.

[aramase]

thanks for adding the details @enj!

this was discussed in the community call and the general consensus was not supporting stringData field in secret objects. The secretObjects field is used solely as a template to read the secrets returned by the provider and setting them in Kubernetes secret.

If folks on this thread are interested, please join the community call (info: https://github.com/kubernetes-sigs/secrets-store-csi-driver#want-to-help) to discuss more.

[anubisg1]

what options do we have then? drupal is not the only one, also opensearch for example, requires to pass an entire yml config file as a secret.. and as you know, it's not a really bright idea to keep such file in clear text inside a manifest

[enj]

what options do we have then? drupal is not the only one, also opensearch for example, requires to pass an entire yml config file as a secret.. and as you know, it's not a really bright idea to keep such file in clear text inside a manifest

If you were using a manually created Kube secret (without this CSI driver), how would you consume the YAML?

[anubisg1]

what options do we have then? drupal is not the only one, also opensearch for example, requires to pass an entire yml config file as a secret.. and as you know, it's not a really bright idea to keep such file in clear text inside a manifest

If you were using a manually created Kube secret (without this CSI driver), how would you consume the YAML?

This only thing that comes to mind is to deal with additional complexity by dealing with repository encryption and similar for example by using https://github.com/bitnami-labs/sealed-secrets

[enj]

what options do we have then? drupal is not the only one, also opensearch for example, requires to pass an entire yml config file as a secret.. and as you know, it's not a really bright idea to keep such file in clear text inside a manifest

If you were using a manually created Kube secret (without this CSI driver), how would you consume the YAML?

This only thing that comes to mind is to deal with additional complexity by dealing with repository encryption and similar for example by using https://github.com/bitnami-labs/sealed-secrets

@anubisg1 not sure I follow - what prevents you from putting the YAML inside a Kube secret and mounting it in the pod as a file (which you can do with or without secrets-store-csi-driver)?

[anubisg1]

what options do we have then? drupal is not the only one, also opensearch for example, requires to pass an entire yml config file as a secret.. and as you know, it's not a really bright idea to keep such file in clear text inside a manifest

If you were using a manually created Kube secret (without this CSI driver), how would you consume the YAML?

This only thing that comes to mind is to deal with additional complexity by dealing with repository encryption and similar for example by using https://github.com/bitnami-labs/sealed-secrets

@anubisg1 not sure I follow - what prevents you from putting the YAML inside a Kube secret and mounting it in the pod as a file (which you can do with or without secrets-store-csi-driver)?

the problem is NOT creating a secret and attacching to the pod, the problem is that secret is NOT encrypted, is only encoded. using the secrets-store-csi-driver i can put the secret a keyvault and then have the secret automatically generated by the secrets-store-csi-driver

[enj]

the problem is NOT creating a secret and attacching to the pod, the problem is that secret is NOT encrypted, is only encoded. using the secrets-store-csi-driver i can put the secret a keyvault and then have the secret automatically generated by the secrets-store-csi-driver

@anubisg1 sure, but then it is still not clear to me what the deficiency is in secrets-store-csi-driver that prevents you from using it?

[anubisg1]

the problem is NOT creating a secret and attacching to the pod, the problem is that secret is NOT encrypted, is only encoded. using the secrets-store-csi-driver i can put the secret a keyvault and then have the secret automatically generated by the secrets-store-csi-driver

@anubisg1 sure, but then it is still not clear to me what the deficiency is in secrets-store-csi-driver that prevents you from using it?

the siple fact that, as described in the original report, you cannot create an secretObject type stringData, therefore you cannot generate a secret dynamically from a vault if that secret is anything else than a key pair

[lstadnik]

I faced with the same issue. Azure Key Vault store the secret in base64 format already (only few of them)- In normal situation you would use such source for secret and instead of data, create stringdata according to the k8s documentation to avoid converting base64 secret again. The secret is generated by secret provided class but it is not supporting stringdata

example

  secretObjects:
  - secretName: trustanchorjks
    type: Opaque
    stringdata:
    - objectName: "trustanchor-jks"
      key: trustanchor-jks