Raise error when unknown key specified in template

[shuheiktgw]

Problem Statement

While working on the template, I noticed if I specify a non-existent key in the template, the reconciliation succeeds and inserts value <no value>. This behavior seems quite error-prone since users could accidentally insert base64 encoded <no value> to their secret value.

Related Issue

N/A

Proposed Changes

Use the missingkey=error option for the go template to raise the error.

Checklist

• I have read the contribution guidelines
• All commits are signed with git commit --signoff
• My changes have reasonable test coverage
• All tests pass with make test
• I ensured my PR is ready for review with make reviewable

[gusfcarvalho]

IIRC this was set on purpose - @moolen do you happen to know what was the reason we did that on purpose?

[moolen]

I don't know, it doesn't ring a bell. From the looks of it i think this is fine.

[gusfcarvalho]

In that case, I think we need to update documentation as well in https://external-secrets.io/latest/guides/templating/:

base64encode was renamed to b64enc.
base64decode was renamed to b64dec. Any errors that occur during decoding are silenced.
fromJSON was renamed to fromJson. Any errors that occur during unmarshalling are silenced.
toJSON was renamed to toJson. Any errors that occur during marshalling are silenced.

As these are no longer silenced if I understand correctly 😄

[shuheiktgw]

Thanks for the feedback! IIUC, the doc states errors returned from those three functions are ignored, I personally believe we don't have to change that part since we keep ignoring those errors even after the change, but WDYT? 🤔

[gusfcarvalho]

wouldn't a (fromJson .).key start failing now?

[shuheiktgw]

wouldn't a (fromJson .).key start failing now?

Yes, that is correct! At the same time, the current statement "fromJSON was renamed to fromJson. Any errors that occur during unmarshalling are silenced." also stays true even after this change. Why don't we simply update the doc and tell users that any missing keys raise an error?

[gusfcarvalho]

wouldn't a (fromJson .).key start failing now?

Yes, that is correct! At the same time, the current statement "fromJSON was renamed to fromJson. Any errors that occur during unmarshalling are silenced." also stays true even after this change. Why don't we simply update the doc and tell users that any missing keys raise an error?

works for me. :) sorry for nitting

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
0.5% Duplication on New Code

See analysis details on SonarCloud

[shuheiktgw]

@gusfcarvalho Thanks, updated the docs!

[gusfcarvalho]

I cannot be more grateful by having you as maintainer 😄

[qlonik]

Hey, just wanted to ask about this. With this change it is now not possible to use .missing_key | default "some-default" anymore, since it throws an error when accessing the missing key. Is there any way to make | default work?

[shuheiktgw]

@qlonik Hmm, yes that is correct... This is more like a Go template level problem, so there must be some ways to workaround the problem so let me check 🙇

[shuheiktgw]

@qlonik I've figured out how we can set the default values without raising errors. If this is a common use case, it might be favorable to add syntax sugar for it...

{{ if index . "missing_key" }}{{ .missing_key }}{{ else }}some-default{{ end }}