Enable encryptedData to be omitted by setting key to null in template

[meln5674]

Description of the change

Make SealedSecret.spec.template.data fields nullable. A null value indicates that the key should be omitted from the final secret.

Change is backwards compatible.

Benefits

Templated Secrets can be used in cases where the set of keys is significant, i.e. extraneous keys are not acceptable.

Possible drawbacks

None known.

Applicable issues

• fixes Selectively omit encryptedData keys when using templates #1870

Additional information

[alvneiayu]

hi @meln5674

there are linter errors. Could you take it a look, please?

thanks

Álvaro

[meln5674]

@alvneiayu It would appear the import and tooling versions have diverged.

3 of the 4 lint findings are deprecated functions called in files I did not modify, but instead the functions themselves are deprecated in the new make generate output, which suggests a version of k8s.io/code-generator other than the one listed in the go.mod was used to generate the current versions. The version annotation on the generated CRD went from 0.15.0 to 0.20.0, which is further evidence of version drift. I also notice the version of sigs.k8s.io/controller-tools/cmd/controller-gen in the Makefile is not pinned to a specific version, and will not have reproducible outputs.

I should also mention, make generate on its own fails as it tries to use a package (cmd/validation-gen) not actually present in that version of that module. I had to use make lint CODEGEN_PKG="$GOPATH/pkg/mod/k8s.io/code-generator@v0.35.1" to get it to run at all.

According to the git history, the version of that module the last time the zz_deepcopy.go file was changed was 0.30.1, but resetting the go.mod version to that results in other errors.

I have fixed the one lint finding that was introduced by one of my changes and also ran make manifests which I neglected to do the first time, but beyond that, let me know how you would like me to proceed.

(As a piece of totally unsolicited advice, from one operator maintainer to another, putting needed tool versions in the go.mod via go get -tool, available since go 1.24, makes problems like this go away, as does running make generate and make manifests in CI and verifying the outputs have not changed)

[github-actions]

This Pull Request has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thank you for your contribution.

[meln5674]

Unstale. Awaiting response.

[github-actions]

This Pull Request has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thank you for your contribution.

[meln5674]

Unstale. Awaiting response.

[alvneiayu]

I will take it a look because other PRs are not having problems with the linters. Looks like something is bumped and it is causing the problem in this PR. I will take it a look ASAP. Thanks @meln5674

[meln5674]

@alvneiayu I lost track of this, but after looking back into this, I identified the issue and submitted a fix here. I believe after this it should work, as it passes both code generation and tests locally.

[alvneiayu]

thanks @meln5674

I will evaluate it again, again thanks for your contribution and for the fixes.

Álvaro

[alvneiayu]

Hi @meln5674

Heads up: #2019 just merged and changes Spec.Template.Data compatibility. After rebasing, these map[string]string literals will fail to compile against your new map[string]*string type:

• sealedsecret_test.go — TestValidateEncryptedDataIgnoresTemplate (2 spots)
• controller_test.go — TestAttemptUnsealIgnoresTemplate (1 spot)

Fix with your someStr() helper, e.g.:

ssecret.Spec.Template.Data = map[string]*string{
"probe": someStr({{ fail "attacker-controlled failure" }}),
}

No logic conflict — just a type fixup.