encryptionconfig: detect typos

[enj]

/kind bug
/kind api-change
/triage accepted
/sig auth
/assign liggitt

kube-apiserver: the `--encryption-provider-config` file is now loaded with strict deserialization, which fails if the config file contains duplicate or unknown fields. This protects against accidentally running with config files that are malformed, mis-indented, or have typos in field names, and getting unexpected behavior. When `--encryption-provider-config-automatic-reload` is used, new encryption config files that contain typos after the kube-apiserver is running are treated as invalid and the last valid config is used.

[enj]

/hold

For API review since this is not technically backwards compatible.

[liggitt]

some prior art linked from #82924:

• kubelet use of strict config decoding (Enable strict serializer in kubelet #83204, warns but falls back)
• kube-scheduler (strict in Enable strict serializer in kube-scheduler #83030, lenient for alpha config versions)
• kube-proxy (strict in , lenient for alpha config versions in Add lenient decoding path for v1alpha1 kube-proxy config #84143)

The consequences of typos in this config file are Really Bad™, so I think there's good cause to be strict. I'm trying to think if there's any benefit to phasing this in over time at all... the only people an immediate tightening would impact in a problematic way are folks who upgraded their API server with no test of their existing invalid config.

[enj]

I'm trying to think if there's any benefit to phasing this in over time at all...

I do not think people would notice a warning in the logs, and if someone really did not care about the typo and just wanted the server to start, they could delete the lines that were invalid.

[liggitt]

I'm trying to think if there's any benefit to phasing this in over time at all...

I do not think people would notice a warning in the logs, and if someone really did not care about the typo and just wanted the server to start, they could delete the lines that were invalid.

I think I agree

[enj]

/hold cancel

[k8s-triage-robot]

This PR may require API review.

If so, when the changes are ready, complete the pre-review checklist and request an API review.

Status of requested reviews is tracked in the API Review project.

[liggitt]

/lgtm
/approve

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 12cec93fdf914ac783aa61a3f6192cf1670d85b7

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: enj, liggitt

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• staging/src/k8s.io/apiserver/pkg/server/options/encryptionconfig/OWNERS [enj,liggitt]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment