CustomResourceDefinition schemas should support $ref

[Jc2k]

What would you like to be added:

I would like to be able to use$ref as part of a CRD schema to enable a somewhat recursive schema to apply validation to child values in a map. Here is a simple JSON schema that shows what I mean.

(When i first opened the ticket I thought I needed patternProperties, and the ticket was about supporting that, but it looks like I should be able to do this with additionalProperties instead?)

{
    "type": "object",
    "oneOf": [
        {
            "properties": {
                "type": {
                    "type": "string",
                    "enum": [
                        "text",
                        "number",
                        "ip",
                    ]
                },
                "description": {
                    "type": "string"
                }
            },
            "additionalProperties": false
        },
        {
            "properties": {
                "type": {
                    "type": "string",
                    "enum": [
                        "object"
                    ]
                },
                "description": {
                    "type": "string"
                },
                "properties": {
                    "type": "object",
                    "additionalProperties": {"$ref": "#"}
                }
            },
            "additionalProperties": false
        }
    ]
}

The intention is to ultimately enable something like:

spec:
  mapping:
    type: object
    properties:
        foo:
          type: string
        bar:
          type: object
          properties:
            baz:
              type: string

As you can see the field names are not known at CRD creation time. This is part of a "glue" operator - generating various configs and "sticking" together various Deployments according to best practice. So I cannot lock down the field names or avoid the recursion.

While I've been able to mock up the validation in JSON schema, obviously kubernetes imposes its own restrictions on top and also uses openapi 3.0, not jsonschema, which is both a subset and a superset of jsonschema. While OpenAPI has shifted from being a subset AND superset of JSON schema in 3.0 to being a superset of JSON schema draft 7 in OpenAPI 3.1, that doesn't help because Kubernetes is still a subset in its own right.

Why is this needed:

Right now, it looks like something like this /might/ allow CRD instances to be created?

{
            "type": "object",
            "properties": {
              "type": {
                "type": "string",
                "enum": ["text", "object"],
              },
              "properties": {
                "type": "object",
                "additionalProperties": true
              }
            }
}

But without nesting, the validation is inadequate and will probably need a admission webhook just to run a full jsonschema validation pass in addition to a minimal CRD one.

I'm also not sure of the implications here for structural schemas, as additionalProperties: true don't feel very structural when the schema of the value is not specified? Would this even be a valid structural schema? It seems like recursive approach might give kubernetes more clues about the structure of a schema than additionalProperties: true can.

[Jc2k]

Related: #59485

/sig api-machinery
/area custom-resources

[liggitt]

Thanks for the request. This is a duplicate of #62872