Template environment substitution (e.g. from Flux) breaks Kubernetes Secrets

[xvzf]

We're using Flux Substitution in combination with tk export in order to pass in some externally managed references and template secrets out of other secrets

e.g. the tanka rendered manifest

apiVersion: v1
kind: Secret
metadata:
  name: test
stringData:
  TEST_INT: ${SOME_INT}

with the variable SOME_INT="1234" would be substituted to

apiVersion: v1
kind: Secret
metadata:
  name: test
stringData:
  TEST_INT: 1234

which is not a valid Kubernetes secret. With Kustomize I used to prevent this by quoting those references:

apiVersion: v1
kind: Secret
metadata:
  name: test
stringData:
  TEST_INT: "${SOME_INT}"

Is this something worth exploring Tanka or an edge case you don't want to support? As mitigation we're now setting SOME_INT="'1234'" which is not very elegant :-)

[Duologic]

Do you have some jsonnet example that i can use to reproduce?

[xvzf]

sure!

local k = (import 'k.libsonnet');

{
  secret:
    k.core.v1.secret.new('test', {})
    + k.core.v1.secret.withStringData({
      TEST_INT: '${SOME_INT}',
    }),
}

renders to:

apiVersion: v1
data: {}
kind: Secret
metadata:
  name: test
  namespace: default
stringData:
  TEST_INT: ${SOME_INT}
type: Opaque

[sh0rez]

so this is really the yaml marshaler deciding it does not need to quote this, right?

seems like there is a way to enforce quoting: go-yaml/yaml#556

not sure how practical it is though, it might require traversing every single manifest looking for such replacement directives. in case it turns out too heavy for tanka, it might be feasible to handle it in a separate binary that gets the piped input from tanka though

[xvzf]

@sh0rez exactly, I've been thinking about a simple sed ... in the CD step but ended up not liking this solution. Since it might be a common issue I've been thinking about a CLI flag to enforce quoting (at least for Secrets & ConfigMaps).

[xvzf]

I'll create a PR the following days

[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.

[ghostsquad]

Probably not stale. 30 days is aggressive. It sometimes takes me months to circle back to a OSS PR.

[xvzf]

Still not stale, did not find the time yet!

[xvzf]

PR is up @sh0rez

Would be great if you can test it on your code-bases as well. I bet they are generating a bit more than ours