Skip to content

Metadata validation for CustomResources #74620

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
roycaihw opened this issue Feb 26, 2019 · 3 comments · Fixed by #77653
Closed

Metadata validation for CustomResources #74620

roycaihw opened this issue Feb 26, 2019 · 3 comments · Fixed by #77653
Labels
area/custom-resources kind/feature Categorizes issue or PR as related to a new feature. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.

Comments

@roycaihw
Copy link
Member

We allow CRD authors to write validation for CustomResources. Currently we don't restrict writing validation for metadata, which means people can have additive validation constraints to metadata after the built-in validation.

For example, people can have additive name constraints (require CR metadata.name to be default) with the following schema:

  validation:
   openAPIV3Schema:
     description: Foo CRD for Testing
     properties:
       metadata:
         description: Metadata of Foo
         properties:
           name:
             description: Name of Foo
             pattern: default
             type: string

This brings us two questions:

  1. how do we publish CR validation schema 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
  1. longer 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 @apelisse @lavalamp @liggitt @mbohlool @smarterclayton @sttts
@roycaihw roycaihw added the kind/feature Categorizes issue or PR as related to a new feature. label Feb 26, 2019
@k8s-ci-robot k8s-ci-robot added sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. area/custom-resources labels Feb 26, 2019
This was referenced Feb 26, 2019
Merged
Closed
@oomichi oomichi mentioned this issue Feb 26, 2019
Closed
@mbohlool
Copy link
Contributor

  • 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

What is the difference between these two? I mean the end result is the same right? The only thing that can be added is validation. Nothing else works unless you are considering extensions?

@roycaihw
Copy link
Member Author

What is the difference between these two?

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.

@liggitt
Copy link
Member

liggitt commented Feb 27, 2019

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

@sttts sttts mentioned this issue May 9, 2019
Merged
@abursavich abursavich mentioned this issue Aug 31, 2020
Closed
cbzzz pushed a commit to linode/cluster-api-provider-linode that referenced this issue Mar 27, 2024
@cbang-akamai
fix: add name validation for custom resources
6ae75ac 
This propagates the label constraints of Linode resources to their associated
CustomResourceDefinitions via the Kubernetes Validation Rules feature. When a
custom resource is created, the Kuberneten object name is validated against the
label constraints of its backing Linode resources. This allows CAPL-managed
resources to maintain a human-readable naming scheme between its Kubernetes
representation and the backing Linode implementation.

Validation rules are implemented via Kustomize JSON patches due to limitations
with Kubebuilder and Strategic Merge Patching with CRDs in Kubernetes.

See:
- https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules
- kubernetes/kubernetes#113223
- kubernetes/kubernetes#74620
- kubernetes-sigs/kubebuilder#1074
cbzzz pushed a commit to linode/cluster-api-provider-linode that referenced this issue Mar 27, 2024
@cbang-akamai
fix: add name validation for custom resources
f29e521 
This propagates the label constraints of Linode resources to their associated
CustomResourceDefinitions via the Kubernetes Validation Rules feature. When a
custom resource is created, the Kuberneten object name is validated against the
label constraints of its backing Linode resources. This allows CAPL-managed
resources to maintain a human-readable naming scheme between its Kubernetes
representation and the backing Linode implementation.

Validation rules are implemented via Kustomize JSON patches due to limitations
with Kubebuilder and Strategic Merge Patching with CRDs in Kubernetes.

See:
- https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules
- kubernetes/kubernetes#113223
- kubernetes/kubernetes#74620
- kubernetes-sigs/kubebuilder#1074
cbzzz pushed a commit to linode/cluster-api-provider-linode that referenced this issue Mar 27, 2024
@cbang-akamai
fix: add name validation for custom resources
df1e6ff 
This propagates the label constraints of Linode resources to their associated
CustomResourceDefinitions via the Kubernetes Validation Rules feature. When a
custom resource is created, the Kuberneten object name is validated against the
label constraints of its backing Linode resources. This allows CAPL-managed
resources to maintain a human-readable naming scheme between its Kubernetes
representation and the backing Linode implementation.

Validation rules are implemented via Kustomize JSON patches due to limitations
with Kubebuilder and Strategic Merge Patching with CRDs in Kubernetes.

See:
- https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules
- kubernetes/kubernetes#74620
- kubernetes-sigs/kubebuilder#1074
- kubernetes/kubernetes#113223
cbzzz pushed a commit to linode/cluster-api-provider-linode that referenced this issue Mar 27, 2024
@cbang-akamai
fix: add name validation for custom resources
0d41fd3 
This propagates the label constraints of Linode resources to their associated
CustomResourceDefinitions via the Kubernetes Validation Rules feature. When a
custom resource is created, the Kubernetes object name is validated against the
label constraints of its backing Linode resources. This allows CAPL-managed
resources to maintain a human-readable naming scheme between its Kubernetes
representation and the backing Linode implementation.

Validation rules are implemented via Kustomize JSON patches due to limitations
with Kubebuilder and Strategic Merge Patching with CRDs in Kubernetes.

See:
- https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules
- kubernetes/kubernetes#74620
- kubernetes-sigs/kubebuilder#1074
- kubernetes/kubernetes#113223
@cbzzz cbzzz mentioned this issue Mar 27, 2024
Merged
4 tasks
@jpbetz jpbetz mentioned this issue Mar 19, 2025
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/custom-resources kind/feature Categorizes issue or PR as related to a new feature. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

apiextensions: disallow metadata specs other than name and generateName sttts/kubernetes
4 participants
@liggitt @mbohlool @roycaihw @k8s-ci-robot
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy