Many of our CNPs and CCNPs have the following form:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
description: "L7 policy for getting started using Kubernetes guide"
metadata:
  name: "l7-policy"
spec:
  endpointSelector:
    matchLabels:
      id: app1
  ingress:
   ...

Note the "description" field is not under spec. This field is misplaced, because we already have a field for this under spec.

The policy should be written as:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "l7-policy"
spec:
  description: "L7 policy for getting started using Kubernetes guide"
  endpointSelector:
    matchLabels:
      id: app1
  ingress:
   ...

This may seem trivial, but as we migrate over to v1 CRDs, "unknown" fields are no longer allowed. They were allowed under v1beta1 CRDs [1]. The top-level "description" is considered "unknown" because it doesn't exist in the validation schema, so K8s does not expect it to be there. To maintain backwards-compatibility and to not break existing policies, support was adding to our fork of controller-tools for generating a top-level "description" field in the validation schema.

We should consider deprecating this top-level field, in favor of the one that already exists for this purpose, and remove it once sufficient time has past.

1: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#field-pruning

For migrated CustomResourceDefinitions where spec.preserveUnknownFields is set, pruning is not enabled and you can store arbitrary data. For best compatibility, you should update your custom resources to meet an OpenAPI schema, and you should set spec.preserveUnknownFields to true for the CustomResourceDefinition itself.