Allow additional metadata properties in constraints.gatekeeper.sh openAPIV3Schema

[wrdls]

Describe the solution you'd like

Allow standard Kubernetes metadata properties in the generated constraint resources. Either by setting additionalProperties or by adding the missing properties.

The metadata section currently only allows for the name property.

gatekeeper/pkg/readiness/testdata/crds/k8shttpsonly_crd.yaml

Lines 23 to 28 in 3e66ee2

	metadata:
	properties:
	name:
	maxLength: 63
	type: string
	type: object

We add some company standard metadata like namespace, labels, and annotations to every resource which includes constraints.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: required-labels
  namespace: gatekeeper
  labels:
    owner: myteam
  annotations:
    argocd.argoproj.io/sync-wave: '2'
spec:
  ...

We validate our generated Kubernetes resources in CI with kubeconform with the --strict flag.

 -strict
        disallow additional properties not in schema or duplicated keys

This causes errors like the following:

    {
      "filename": "rendered.yaml",
      "kind": "K8sRequiredLabels",
      "name": "required-labels",
      "version": "constraints.gatekeeper.sh/v1beta1",
      "status": "statusInvalid",
      "msg": "For field metadata: Additional property annotations is not allowed - For field metadata: Additional property namespace is not allowed"
    },

Anything else you would like to add:

Our current workaround is to filter out the constraint resources before running kubeconform.

I also added a feature request in yannh/kubeconform#169 to be able to ignore all constraint resources, but I do feel this should also be fixed here.

Environment:

• Gatekeeper version: 3.11.0
• Kubernetes version: (use kubectl version): 1.24.10

[maxsmythe]

one note: namespace cannot be defined, since constraints are cluster-scoped.

IIRC adding more metadata validation beyond name length may break CRDs in K8s.

From https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema :

if metadata is specified, then only restrictions on metadata.name and metadata.generateName are allowed.

It would be nice to be able to inherit K8s' metadata schema somehow.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[wrdls]

You're right about namespaces, but only allowing name is not correct.

Some options that I see:

• Define additionalProperties to something else than false
• Simplify metadata to

"metadata": {
      "type": "object"
    }

• Reference an existing schema (although I understand if you don't want external dependencies), e.g. https://github.com/yannh/kubernetes-json-schema/blob/master/v1.25.13/configmap-v1.json#L58-L61

[maxsmythe]

You're right about namespaces, but only allowing name is not correct.

In what sense is this not correct? Is it possible to create a CRD in a running K8s cluster that allows restricting/defining metadata fields other than name? The problem would be K8s disallowing creation of the CRD.

[wrdls]

Because this is not valid resource according to the generated schema by gatekeeper:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: required-labels
  labels:
    owner: myteam
  annotations:
    argocd.argoproj.io/sync-wave: '2'

In what way is this not a valid Kubernetes resource?

E.g. Prometheus has just type object https://github.com/prometheus-community/helm-charts/blob/main/charts/kube-prometheus-stack/charts/crds/crds/crd-prometheuses.yaml#L65-L66

[maxsmythe]

Please refer to my original link to Kubernetes' docs in my first reply:

From https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema :

if metadata is specified, then only restrictions on metadata.name and metadata.generateName are allowed.

According to the Kubernetes docs, if you try to kubectl apply a CRD with an opinion on metadata other than name length, the cluster will reject it.

[maxsmythe]

To be clear, if you can provide an example CRD definition that does what you want that you can successfully apply on a standard K8s cluster, I'd be happy to take a closer look.

[maxsmythe]

One other issue would be how divergent the schemas can be. If a newer version of K8s adds a new metadata field, our CRD would not have that field.

If that turned out to break our ability to apply CRDs, that would be bad.

These are things to watch out for, assuming that this is undocumented behavior which may or may not be considered part of the k8s API

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.