CRDs Catalog

---

Catalog of Kubernetes CustomResourceDefinition JSON schemas for validating custom resources with tools such as kubeconform or datree.

Purpose

Kubernetes native schemas do not cover custom resources. This repository provides JSON schemas for selected CRDs so they can be validated in CI, locally, or in editors without access to a live cluster.

Use cases:

• validate manifests with kubeconform
• validate manifests with datree
• improve editor validation / autocompletion for CRs
• keep a local, versioned catalog of CRD schemas

This aligns with how kubeconform supports additional schema locations for CRDs and how CRD catalogs are commonly consumed for offline or shift-left validation. citeturn0search2turn0search4turn0search1

Repository layout

Schemas are grouped by API group at the repository root.

Example:

• cert-manager.io/
• monitoring.coreos.com/
• snapshot.storage.k8s.io/

Inside each directory, schema files should follow a predictable naming convention per resource kind and API version so validation tools can resolve them consistently. This matches the common CRD catalog pattern used with kubeconform. citeturn0search1turn0search2

Usage

Kubeconform

kubeconform supports one or more custom schema locations for CRDs. citeturn0search2turn0search4

kubeconform \
  -schema-location default \
  -schema-location 'https://raw.githubusercontent.com/hoverkraft-tech/crds-catalog/main/{{.Group}}/{{.ResourceKind}}_{{.ResourceAPIVersion}}.json' \
  path/to/manifests.yaml

Datree

datree can validate Kubernetes manifests locally as part of a shift-left workflow. citeturn0search0turn0search1

If you use this repository as a schema source in your workflow, keep the catalog available locally or reference the raw files directly from your validation pipeline.

Contributing

Contributions should add or update JSON schemas for public Kubernetes CRDs.

Guidelines:

• group schemas by API group
• keep file naming consistent
• prefer generated schemas from upstream CRDs when possible
• update existing schemas when CRDs change upstream
• avoid adding unrelated tooling or generated noise

For missing CRDs, the safest approach is to extract or generate schemas from the upstream CRD definitions and commit the resulting JSON schema artifacts. This is consistent with how CRD validation catalogs are typically maintained. citeturn0search1turn0search2

Scope

This repository is intended to be:

• simple
• consumable by automation
• easy to vendor or mirror internally

It is not intended to replace upstream CRD sources. Upstream projects remain the source of truth for CRD definitions.

License

Add the project license here if/when a license file is included in the repository.