No Schema for SecretProviderClass manifests

[jpbulloch5]

There are currently no schemas for SecretProviderClass (used in our case for connecting Azure Key Vaults to our Deployments).

Azure Documentation related to our use case:
https://learn.microsoft.com/en-us/azure/aks/csi-secrets-store-driver#sync-mounted-content-with-a-kubernetes-secret

Currently, the lack of a schema for SecretProviderClass manifests means we have to use --ignore-missing-schemas in our pipelines when linting our Kubernetes manifests.

Thanks!

[eyarz]

@jpbulloch5 SecretProviderClass are not native K8s objects (they are CRDs), so they are not part of the default schemas that are checked by Kubeconform.

You can use Kubeconform and set the CRDs-catalog as an external schema location. This will work because SecretProviderClass are already part of the catalog.

[yannh]

@eyarz Maybe we could link to the CRD catalog in the README

[eyarz]

@eyarz Maybe we could link to the CRD catalog in the README

Sure! I will open a PR.

[jpbulloch5]

Our CI/CD use case pipes the output from kustomize build to kubeval to check that the manifests build correctly from their Kustomize templates. We are not checking each manifest independently, so I hoped for a solution that used kubeval since it works for the rest of our manifests without issue.

[eyarz]

In the CRDs-catalog repo, you also have instructions on how to use it with kubeval.

[jpbulloch5]

As a custom solution based on your feedback (thanks), I added the following to the dockerfile for the custom image that runs the kubeval lint job in our CI/CD pipelines:

RUN mkdir --parents crd-schemas/master-standalone-strict \
    && wget \
        --quiet \
        --output-document crd-schemas/master-standalone-strict/secretproviderclass-secrets-store-v1alpha1.json \
        https://raw.githubusercontent.com/datreeio/CRDs-catalog/main/secrets-store.csi.x-k8s.io/secretproviderclass_v1alpha1.json

In the script that executes the job I added file:/crd-schemas to our list of --additional-schema-locations.
That fixed it for our use case.