Input stringData gets stripped completely

[danopia]

It appears as though the redactSecrets method is using stringData as a behind-the-scenes crutch to print a redacted data diff:

helm-diff/diff/diff.go

Lines 94 to 129 in 818e596

	if old != nil {
	oldSecret.StringData = make(map[string]string, len(oldSecret.Data))
	for k, v := range oldSecret.Data {
	if new != nil && bytes.Equal(v, newSecret.Data[k]) {
	oldSecret.StringData[k] = fmt.Sprintf("REDACTED # (%d bytes)", len(v))
	} else {
	oldSecret.StringData[k] = fmt.Sprintf("-------- # (%d bytes)", len(v))
	}
	}
	}
	if new != nil {
	newSecret.StringData = make(map[string]string, len(newSecret.Data))
	for k, v := range newSecret.Data {
	if old != nil && bytes.Equal(v, oldSecret.Data[k]) {
	newSecret.StringData[k] = fmt.Sprintf("REDACTED # (%d bytes)", len(v))
	} else {
	newSecret.StringData[k] = fmt.Sprintf("++++++++ # (%d bytes)", len(v))
	}
	}
	}
	// remove Data field now that we are using StringData for serialization
	var buf bytes.Buffer
	if old != nil {
	oldSecret.Data = nil
	if err := serializer.Encode(&oldSecret, &buf); err != nil {
	}
	old.Content = getComment(old.Content) + strings.Replace(strings.Replace(buf.String(), "stringData", "data", 1), " creationTimestamp: null\n", "", 1)
	buf.Reset() //reuse buffer for new secret
	}
	if new != nil {
	newSecret.Data = nil
	if err := serializer.Encode(&newSecret, &buf); err != nil {
	}
	new.Content = getComment(new.Content) + strings.Replace(strings.Replace(buf.String(), "stringData", "data", 1), " creationTimestamp: null\n", "", 1)

The issue is that if the chart being diffed uses stringData then all those fields are completely hidden from the diff output. For example, this template:

---
apiVersion: v1
kind: Secret
metadata:
  name: {{ $config.name }}
type: Opaque
stringData:
  kongCredType: acl
  group: inbound-traffic
  otherField: |
    Lorem ipsum dolor sit amet, consectetur adipiscing elit.
    Sed sed felis id ex ultricies tempor.

shows as this in helm-diff:

my-namespace, my-name, Secret (v1) has been added:
+ # Source: secret.yaml
+ apiVersion: v1
+ kind: Secret
+ metadata:
+   name: my-name
+ type: Opaque

This effectively defeats the diffing for any secret values that do not need to be redacted.

[databus23]

I see. Thanks for reporting this. So I think what should happen here is that we need to consider that stringData might not be empty. If its not empty we need to redact the fields in place and only add fields from data that are not already present in stringData. Would you agree?

[danopia]

In my opinion, I don't actually care about redaction for stringData fields; it's basically a statement that something else expects the data in a Secret even though it's human readable plaintext and I don't want to deal with obfuscation.

Disregarding my opinion, your plan looks sound :) The distinction between stringData and data would get lost in the diff, which sounds reasonable because the distinction also gets lost once in the cluster.

I'd be happy either way (with or without stringData redaction) as long as the diff stops incorrectly hiding entire fields.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[guillomep]

I also have a similar problem with stringData.
I have a chart that only deploy a secret containing a stringData
When I changed the content of the stringData the diff output no modification instead of saying that the secret is modify, meaning that if I do a helmfile apply nothing is done.
The workaround I found is to add an annotation to my secret and change the value when I change the data.

To reproduce:

1. Deploy a secret containing stringData with the chart incubator/raw
2. Modify the secret stringData
3. Execute helm diff

Nothing is displayed.

[ccodreanu]

experiencing this as well with stringData secrets

[mayconritzmann]

Hey, guys!
I had the same problem, to work around it, I added this to my template file:

---
apiVersion: v1
kind: Secret
metadata:
  name: {{ include "alertmanager.config.secret" . }}
  labels:
    {{ include "alertmanager.labels" . | indent 4 | trim }}
    release: {{ .Release.Name }}
  annotations:
    rollme: {{ randAlphaNum 5 | quote }}

[majewsky]

In my opinion, I don't actually care about redaction for stringData fields; it's basically a statement that something else expects the data in a Secret even though it's human readable plaintext and I don't want to deal with obfuscation.

Counter-point: After running into this issue in our own Helm toolchain, I surveyed our Helm charts for usage of stringData and found a fair amount of secrets that use stringData for actual credentials. My guess is that it's just more convenient and/or more obvious for chart authors to write:

stringData:
  foo_password: "{{ .Values.foo_service.password }}"
  bar_token: "{{ .Values.bar_service.token }}"

instead of:

data:
  foo_password: "{{ .Values.foo_service.password | b64enc }}"
  bar_token: "{{ .Values.bar_service.token | b64enc }}"