xref #59984 #60635 #57615 #52936 #59593 #60934 #61623 #61984 #62987 #63426 #65470 for wanting to tighten validation

wanting to loosen validation:

• [Need-Feedback] Support Volume Expansion Through StatefulSets #71384 (comment)
• Added ':' in environment variable name valid characters list #69415 (comment)
• Add StatefulSet Volume Expansion Kep enhancements#660 (comment)

a methodical way to do ratcheting validation would be ideal:

• apply tightened validation on create
• apply tightened validation on update where the old object passed this validation (don't let a valid object become invalid)
• skip tightened validation on update where the old object fails this validation

Yes, that's the mechanism I had in mind when I wrote the two bullet points in the original post.

(also thanks for the extensive list of cross references)

/cc @mbohlool

/assign

WIP in #64907

xref #64532

Sorry for not noticing this earlier.

Tightening validation can break clients. I don't see much of a way around that. Special-casing updates protects the apiserver but not clients and users.

It seems like the only recourse would be to downgrade to the prior release until the clients can be fixed. And downgrade is known to not work in the general case.

Maybe we need an advisory mode that also applies to create, so that users can debug problems before they irreversibly hose their clusters?

https://github.com/kubernetes/community/blob/master/contributors/devel/api_changes.md#backward-compatibility-gotchas

Changing any validation rules always has the potential of breaking some client, since it changes the assumptions about part of the API, similar to adding new enum values. Validation rules on spec fields can neither be relaxed nor strengthened. Strengthening cannot be permitted because any requests that previously worked must continue to work. Weakening validation has the potential to break other consumers and generators of the API resource. Status fields whose writers are under our control (e.g., written by non-pluggable controllers), may potentially tighten validation, since that would cause a subset of previously valid values to be observable by clients.

The end of that should be: "to no longer be observable by clients"

The list of cross references was useful.

We should document how to handle common cases, such as duplicate list entries.

It looks like maybe a few of them wouldn't have worked, but with asynchronous failures rather than synchronous ones.

However, it's possible for cases we didn't intend to be supported, such as multiple instances of the same environment variable, to be working for someone.

Other thoughts:

We also need to demand validation tests that fail for every field that doesn't accept all values of the base type.

This doesn't handle cases where contributors introduce new validation checks outside the ratcheting mechanism. What are we trying to defend against?

The cluster admin will want to know if any of potential problems. We need to introduce exported variables that surface affected resource types.

Tightening validation can break clients. I don't see much of a way around that. Special-casing updates protects the apiserver but not clients and users.

What are we protecting clients and users from? My intent with these was to only address validation gaps that were allowing in fatally flawed objects.

It seems like the only recourse would be to downgrade to the prior release until the clients can be fixed.

Is it a great loss to block a client that is submitting deployments/pods that can not succeed? Is the concern that such a client would not back off and would perpetually attempt to create the objects? Doesn't that risk already exist with dynamic reasons for denial (quota, authorization, webhook admission)?

any requests that previously worked must continue to work

what does that mean for an object which, if created, can not work properly, and will inevitably fail asynchronously (sometimes taking a long time to do so, as in the case of the duplicate PVC volume refs)? the fixes in the linked PR were intended to resolve problems of that variety.

The only one I could see being questionable is the duplicate envvar fix. That seemed valuable to prevent because it is known to cause data loss when using apply to try to remove the extra envvar on an update, but I can pull that one out if we'd rather try to think of a different way to address that (since a pod with that duplication can still run successfully)

Added to the SIG Arch backlog: https://github.com/kubernetes-sigs/architecture-tracking/projects/3

@liggitt I agree with respect to requests that were fatally flawed. However, we haven't always been correct when trying to identify such cases in the past.

Example:

It looks like unknown emptyDir medium values succeed:

	if buf.Type == linuxTmpfsMagic {
		return v1.StorageMediumMemory, !notMnt, nil
	} else if int64(buf.Type) == linuxHugetlbfsMagic {
		return v1.StorageMediumHugePages, !notMnt, nil
	}
	return v1.StorageMediumDefault, !notMnt, nil

It looks like unknown emptyDir medium values succeed

If that's the case, I agree it shouldn't be tightened. I was going off of #52936 (comment)

Sorry, that's not the right check.

So, maybe not:

But, anyway, my point is sometimes these can unintentionally succeed

Yeah, point taken. I put a hold on the PR until we can think through whether this approach is a net positive. If we end up moving forward with it, we'll need to be really clear about the types of scenarios where it is an appropriate tool to use.

@liggitt One approach could be to write tests that demonstrate asynchronous failure and commit them before enabling new validation.

I also think we need to start requiring tests for issues such as duplicate entries in associative lists ASAP.

Along those lines, I actually don't think the integer memory requirement should be included. I can successfully start a pod with fractional memory requirements, which just get rounded when necessary.

Would it be possible to implement a tighter validation as a validating webhook, that the cluster admin can decide to enable/disable? There could even be a way (annotation?) to ignore specific objects known to be broken.

One approach could be to write tests that demonstrate asynchronous failure and commit them before enabling new validation.

Good idea.

I also think we need to start requiring tests for issues such as duplicate entries in associative lists ASAP.

Yes. Validation in general tends to get little attention in new API PRs.

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#backward-compatibility-gotchas

There's another way validation changes can break clients. By e.g. permitting formerly disallowed field contents, e.g. a new character in a name. Clients that depended on the former limited expressiveness could be broken. This is similar to the problem that obtains when one adds an enum value.

Detecting this in a fully general way is going to be hard to impossible, because the error happens after the client has done a read. The error may actually be very subtle and not cause a crash (imagine allowing / in some field which then leads to a client having a path traversal vulnerability).

There's another way validation changes can break clients. By e.g. permitting formerly disallowed field contents, e.g. a new character in a name. Clients that depended on the former limited expressiveness could be broken.

Correct. #63362 (comment) are the types of questions we need to ask in cases like that.

This is similar to the problem that obtains when one adds an enum value.

At least with enums, we have the option (when defining the field for the first time) to specify what a client should do if it encounters an unknown enum value.

At least with enums, we have the option (when defining the field for the first time) to specify what a client should do if it encounters an unknown enum value.

Clients which ignore suggestions like that will still exist, so it doesn't seem like a solution to me.

we have the option (when defining the field for the first time) to specify what a client should do if it encounters an unknown enum value.

Yeah, it feels more like it's up to client to decide what to do with unknown enum values. At least for enum values they can expect that MAYBE it's going to change in the future and plan accordingly. For value validation, there isn't much they can do.

We don't currently validate that loadBalancerIP, loadBalancerSourceRanges, externalIPs match the ipfamily of the cluster. And we do have users with resources that has this broken behavior. This comment is for tracking only. Actions will be planned later. @liggitt @thockin

• this is still important
• serverside apply in particular is probably going to drive some schema changes that will need this
• My Validation Tightening is not Generally Possible #64841 (comment) above (plus following clarifications) is still how I want to deal with this
• validation relaxation actually needs to go through this process in reverse to preserve downgradability.

/wg apply