feat(secrets): allow diffing stringData sections of secrets as well as data sections

[philomory]

Fixes #302.

If the same key appears in both the data and stringData sections of the same secret, the one in the stringData section is the one considered, because that is how Kubernetes itself behaves.

[mumoshu]

I might be confused, but shouldn't we reset the whole newSecret.Data before merging in StringData entries? Otherwise, it might get redundant keys when you have different set of keys for data and stringData respectively?

In other words, what if the input was like:

data:
  foo: <BASE64 encoded value "FOO">
  bar: <BASE64 encoded value "BAR1">
stringData:
  bar: BAR2
  baz: BAZ

Should this function output:

stringData:
  foo: FOO
  bar: BAR2
  baz: BAZ

or

stringData:
  bar: BAR2
  baz: BAZ

?

[philomory]

This is to handle the case where the incoming YAML manifest looks as follows:

apiVersion: v1
kind: Secret
metadata:
  name: example
data:
  foo: <encoded:FOO>
  bar: <encoded:BAR>
stringData:
  bar: BAR2
  baz: BAZ

In such a case, per the Kubernetes documentation, the effective value of such a manifest is as follows:

apiVersion: v1
kind: Secret
metadata:
  name: example
data:
  foo: <encoded:FOO>
  bar: <encoded:BAR2>
  baz: <encoded:BAZ>

... or, equivalently:

apiVersion: v1
kind: Secret
metadata:
  name: example
stringData:
  foo: FOO
  bar: BAR2
  baz: BAZ

This is a pretty edge-case scenario: it's perfectly legal to write, but pretty uncommon because it accomplishes so very little other than causing confusion (especially since, once the API server persists the object, the distinction between data and stringData is lost entirely).

[philomory]

@mumoshu Specifically, reference the following from the Kubernetes documentation:

All key-value pairs in the stringData field are internally merged into the data field. If a key appears in both the data and the stringData field, the value specified in the stringData field takes precedence.

[philomory]

@mumoshu Were there any other questions you had about this?

[databus23]

Superseded by #407