Skip to content

Enforce structural rules in CRD OpenAPIv3 schema validation #131836

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.

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tomoish
Copy link
Contributor

@tomoish tomoish commented May 18, 2025

What type of PR is this?

/kind bug

What this PR does / why we need it:

Tightens CRD OpenAPI v3 validation. A schema that sets items,
properties, or additionalProperties is now accepted only when
the owning schema declares the matching type:

  • items : parent type must be "array"
  • properties: parent type must be "object"
  • additionalProperties: parent type must be "object"

These checks keep CRDs structurally valid, prevent runtime panics, and
align the apiserver with OpenAPI v3 constraints.

Key changes

  • Add logic to ValidateCustomResourceDefinitionOpenAPISchema
  • Extend unit tests to cover the new conditions
  • Remove redundant expectations in existing tests

Which issue(s) this PR fixes:

Fixes #126273

Special notes for your reviewer:

Does this PR introduce a user-facing change?

CRD OpenAPI v3 validation now rejects schemas that set `items` when the parent type is not `"array"`, or `properties` / `additionalProperties` when the parent type is not `"object"`.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:


Add strict checks so that a schema containing `items`, `properties`, or
`additionalProperties` is only accepted when the parent `type` is
`array` or `object` as required:

* `items` allowed only when `type: array`
* `properties` allowed only when `type: object`
* `additionalProperties` allowed only when `type: object`

These rules prevent non-structural schemas from being stored in Custom
Resource Definitions and avoid runtime panics or inconsistent behavior.
@k8s-ci-robot k8s-ci-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. do-not-merge/needs-kind Indicates a PR lacks a `kind/foo` label and requires one. do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels May 18, 2025
@k8s-ci-robot
Copy link
Contributor

Hi @tomoish. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

@k8s-ci-robot k8s-ci-robot added needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API and removed do-not-merge/needs-kind Indicates a PR lacks a `kind/foo` label and requires one. labels May 18, 2025
@k8s-ci-robot k8s-ci-robot requested review from cici37 and yujuhong May 18, 2025 13:23
@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: tomoish
Once this PR has been reviewed and has the lgtm label, please assign smarterclayton for approval. For more information see the Code Review Process.

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

Needs approval from an approver in each of these files:

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

@tomoish
Copy link
Contributor Author

tomoish commented May 18, 2025

/sig api-machinery
/kind bug

@k8s-ci-robot k8s-ci-robot added sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. kind/bug Categorizes issue or PR as related to a bug. and removed do-not-merge/needs-sig Indicates an issue or PR lacks a `sig/foo` label and requires one. labels May 18, 2025
@k8s-triage-robot
Copy link

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.

@Jefftree
Copy link
Member

/cc @jpbetz @sttts
/triage accepted

@k8s-ci-robot k8s-ci-robot requested review from jpbetz and sttts May 20, 2025 20:15
@k8s-ci-robot k8s-ci-robot added triage/accepted Indicates an issue or PR is ready to be actively worked on. and removed needs-triage Indicates an issue or PR lacks a `triage/foo` label and requires one. labels May 20, 2025
@jpbetz
Copy link
Contributor

jpbetz commented May 20, 2025

While I would love to clean this up. I'm hesitant because it could break in-use CRDs. Having both "items" and "properties" is allowed today and so it's possible to have CRDs that work fine. While the schemas for such a CRD are clearly a mess, and as much as I'd like to make that better, I don't really want to cause production issues by making such CRDs invalid.

I support modifying validation to return warnings in these cases.

@JoelSpeed @yongruilin - Could we also lint CRDs for this?

@JoelSpeed
Copy link
Contributor

This is definitely something we should be linting, making sure that all markers are applied to the correct object vs array vs other (int/string etc)

I'll create an issue

@jpbetz
Copy link
Contributor

jpbetz commented May 21, 2025

@liggitt suggested we also check what we publish to /openapi for cases like this. If the CRD schema has type=object with both items and properties set, we should not show the items in published openapi.

This sounds like a great idea to me.

@k8s-ci-robot k8s-ci-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 26, 2025
@k8s-ci-robot
Copy link
Contributor

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. kind/api-change Categorizes issue or PR as related to adding, removing, or otherwise changing an API kind/bug Categorizes issue or PR as related to a bug. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. needs-priority Indicates a PR lacks a `priority/foo` label and requires one. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. release-note Denotes a PR that will be considered when it comes time to generate release notes. sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. size/L Denotes a PR that changes 100-499 lines, ignoring generated files. triage/accepted Indicates an issue or PR is ready to be actively worked on.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Adding additional guards on CRD schema
6 participants