CRD generation with `#[serde(deny_unknown_fields)]` applies both `additionalProperties` and `properties`

[peasee]

Current and expected behavior

Consider the following CRD:

#[derive(CustomResource, Deserialize, Serialize, Clone, Debug, JsonSchema)]
#[kube(
    kind = "MyCRD",
    group = "example.com",
    version = "v1",
    namespaced
)]
pub struct MyCRDSpec {
    pub subitem: SubItemDenyUnknown,
}

#[derive(Deserialize, Serialize, Clone, Debug, JsonSchema)]
#[serde(deny_unknown_fields)]
pub struct SubItemDenyUnknown {
    pub one: String,
    pub two: bool,
    pub three: i32,
}

When #[serde(deny_unknown_fields)] is specified, this generates a CRD with both a additionalProperties: false, and properties: of the SubItemDenyUnknown object itself:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: mycrds.example.com
spec:
  group: example.com
  names:
    categories: []
    kind: MyCRD
    plural: mycrds
    shortNames: []
    singular: mycrd
  scope: Namespaced
  versions:
  - additionalPrinterColumns: []
    name: v1
    schema:
      openAPIV3Schema:
        description: Auto-generated derived type for MyCRDSpec via `CustomResource`
        properties:
          spec:
            properties:
              subitem:
                additionalProperties: false
                properties:
                  one:
                    type: string
                  three:
                    format: int32
                    type: integer
                  two:
                    type: boolean
                required:
                - one
                - three
                - two
                type: object
            required:
            - subitem
            type: object
        required:
        - spec
        title: MyCRD
        type: object
    served: true
    storage: true
    subresources: {}

Because this object already contains properties, I would expect additionalProperties to not be specified here as it results in a Kubernetes CRD validation error:

Forbidden: additionalProperties and properties are mutual exclusive

Possible solution

I saw a similar issue in #844. I am not sure if a similar fix is applicable here. I think omitting additionalProperties: false entirely might be more applicable (see context).

Additional context

The CRD Validation page in the Kubernetes docs states:

The field additionalProperties cannot be set to false.

It doesn't seem like this returns an error though, as I tried applying this CRD which applied successfully but pruned the additionalProperties: false from the actual applied CRD. The CRD I applied:

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: mycrds.example.com
spec:
  group: example.com
  names:
    categories: []
    kind: MyCRD
    plural: mycrds
    shortNames: []
    singular: mycrd
  scope: Namespaced
  versions:
  - additionalPrinterColumns: []
    name: v1
    schema:
      openAPIV3Schema:
        description: Auto-generated derived type for MyCRDSpec via `CustomResource`
        properties:
          spec:
            properties:
              one:
                type: string
              two:
                type: object
                additionalProperties: false
            required:
            - one
            type: object
        required:
        - spec
        title: MyCRD
        type: object
    served: true
    storage: true
    subresources: {}

And this is what ended up on my cluster:

spec:
  conversion:
    strategy: None
  group: example.com
  names:
    kind: MyCRD
    listKind: MyCRDList
    plural: mycrds
    singular: mycrd
  scope: Namespaced
  versions:
  - name: v1
    schema:
      openAPIV3Schema:
        description: Auto-generated derived type for MyCRDSpec via `CustomResource`
        properties:
          spec:
            properties:
              one:
                type: string
              two:
                type: object
            required:
            - one
            type: object
        required:
        - spec
        title: MyCRD
        type: object
    served: true
    storage: true
    subresources: {}
status:
  acceptedNames:
    kind: MyCRD
    listKind: MyCRDList
    plural: mycrds
    singular: mycrd
  conditions:
  - lastTransitionTime: "2025-09-25T06:25:43Z"
    message: no conflicts found
    reason: NoConflicts
    status: "True"
    type: NamesAccepted
  - lastTransitionTime: "2025-09-25T06:25:43Z"
    message: the initial names have been accepted
    reason: InitialNamesAccepted
    status: "True"
    type: Established
  storedVersions:
  - v1

Environment

I am running with kind, using a regular kind create cluster:

Client Version: v1.33.4
Kustomize Version: v5.6.0
Server Version: v1.33.1

Configuration and features

k8s-openapi = { version = "0.26.0", features = ["latest", "schemars"] }
kube = { version = "2.0.1", features = ["runtime", "client", "derive"] }

YAML

No response

Affected crates

No response

Would you like to work on fixing this bug?

yes

[peasee]

Some additional testing. It seems additionalProperties: false does actually have an effect even though the docs seem to state otherwise. Specifying a .spec.two.key1 when additionalProperties: false:

The MyCRD "testing" is invalid: spec.two: Invalid value: "key1": spec.two.key1 in body is a forbidden property

When no additionalProperties field is defined at all though:

Error from server (BadRequest): error when creating "resource.yaml": MyCRD in version "v1" cannot be handled as a MyCRD: strict decoding error: unknown field "spec.two.key1"

I think based on this, we should just remove the field when it is additionalProperties: false and properties also exists

[clux]

Hey, thanks for the issue. This does indeed look wrong, but it's probably something that ought to be fixed in schemars, the schema that pops out there is mostly vanilla JsonSchema under the hood in kube.

I see they had a similar issue for enums GREsau/schemars#164

[peasee]

I'm not sure this would result in a schemars fix. It seems to me that additionalProperties: false with a properties: field is a valid JSON schema: https://json-schema.org/understanding-json-schema/reference/object#additionalproperties

It seems the restriction is from Kubernetes to make them mutually exclusive.