Code change:
allErrs = append(allErrs, field.Invalid(fldPath.Child("type"), s.Type, "must be object at the root")) } <ins> // restrict metadata schemas to name and generateName only if metadata, found := s.Properties["metadata"]; found && lvl == rootLevel { // metadata is a shallow copy. We can mutate it. _, foundName := metadata.Properties["name"] _, foundGenerateName := metadata.Properties["generateName"] if foundName && foundGenerateName && len(metadata.Properties) == 2 { metadata.Properties = nil } else if (foundName || foundGenerateName) && len(metadata.Properties) == 1 { metadata.Properties = nil } metadata.Type = "" if metadata.ValueValidation == nil { metadata.ValueValidation = &ValueValidation{} } if !reflect.DeepEqual(metadata, Structural{ValueValidation: &ValueValidation{}}) { // TODO: this is actually a field.Invalid error, but we cannot do JSON serialization of metadata here to get a proper message allErrs = append(allErrs, field.Forbidden(fldPath.Child("properties").Key("metadata"), "must not specify anything other than name and generateName, but metadata is implicitly specified")) } } </ins> if s.XEmbeddedResource && !s.XPreserveUnknownFields && s.Properties == nil { allErrs = append(allErrs, field.Required(fldPath.Child("properties"), "must not be empty if x-kubernetes-embedded-resource is true without x-kubernetes-preserve-unknown-fields")) }

Related discussion:
text: We allow CRD authors to write . Currently we don't restrict writing validation for , which means people can have . For example, people can have additive name constraints (require CR to be ) with the following schema: This brings us two questions: do we if "metadata" is included in the schema: simplest option is to publish standard metav1.ObjectMeta schema info, and use any CRD-specified "metadata" properties as additive validation (just like in-tree types do, publishing standard ObjectMeta schema info, and implementing type-specific name validation internally) alternatively, we can try merging user-specified metadata schema with the standard one. Technically people should only add extra validation to existing metadata properties (adding new fields to metadata won't work since they will be pruned by built-in validation first), but it's unclear to me how arbitrary people may want the metadata validation to be term question is whether to allow people specifying metadata validation at all, or just allow a subset (like name validation) in CRD v1 /sig api-machinery /area custom-resources cc
What is the difference between these two? I mean the end result is the same right? The only thing that can be is validation. Nothing else works unless you are considering extensions?
The former means we drop/hide user-specified metadata schema when we publish CRD OpenAPI. We still validate user-specified constraints on server side, but client-side validation won't see them. The latter enables client-side user-specified metadata validation.
If it's possible to merge with standard metadata schema info, or at the cost of not publishing the standard schema. My inclination would be to publish the complete standard schema for metadata/apiVersion/kind, which we know is complete and accurate, and use and user-specified schema for those fields as addition validations server side