kubernetes: Strip unknown fields in custom resources

For native resources, if an unknown field is specified, it will be ignored and dropped.

Current behaviour of custom resources: all (valid) fields are accepted and persisted. This means that custom resources do not behave like native resources now.

This can be fixed by mentioning fields in the properties construct of the CRD validation schema. New fields which are not specified here will be stripped.

As discussed in the sig api-machinery meeting:

We add this to beta but this will be off by default. We warn when objects will be stripped.
For GA, flip default to on.

Note: additionalProperties will not be allowed to set to false and we will not allow it to be set a schema. It will always be set to true. See discussion in https://github.com/kubernetes/kubernetes/pull/58746.

/sig api-machinery /area custom-resources /kind feature /assign

/cc @sttts @deads2k @liggitt @ash2k @mbohlool @lavalamp @jennybuckley @munnerz @colemickens @frankgreco

About this issue

Original URL
State: closed
Created 6 years ago
Reactions: 3
Comments: 26 (24 by maintainers)

Most upvoted comments

Further thoughts: no, I was right to begin with 😉 apiservers that don’t understand a field should reject it no matter what, even if it’s correct but from a future version of the schema: they can’t know that. Clients deserve to know they’re talking to an old apiserver, and that new features won’t work. The error message should be different, true (“not a valid field” vs “I don’t speak that revision of the API”), but that’s a nice-to-have.

Literally the ONLY people happy we’re dropping the field on the floor are people with a bunch of old, broken manifests that they don’t want to fix. And we don’t know how many people there are like that, and we don’t even know for sure they don’t want to fix their broken manifests.

@liggitt @sttts thoughts?

lavalamp on May 22, 2018