CRD Validation Webhook Schema Inspector

The Incident (What does the error mean?)

Raw webhook rejection from kubectl apply:

Error from server: error when creating "myresource.yaml":
admission webhook "validate.myoperator.io" denied the request:
Invalid value: 0: must be greater than 0 (spec.replicas)

Or from the API server's built-in CRD structural schema validation:

The MyResource "my-app" is invalid:
spec.replicas: Invalid value: 0: must be greater than 0

Immediate consequence: The resource object is never persisted to etcd. Your operator never reconciles it. If this is a rollout, the deployment is silently blocked — no pods are created, no error surfaces in the workload itself, only in the kubectl apply output or CI pipeline logs.

The Attack Vector / Blast Radius

This is not just a typo problem. There are two distinct failure modes:

1. Operator schema is too strict (your schema, your bug) You defined minimum: 1 in the CRD OpenAPI schema for a field like replicas, timeout, maxRetries, or port. A developer legitimately sets replicas: 0 to scale down a workload — a valid operational intent — and the webhook hard-blocks it. Blast radius: Any automation (GitOps, Argo CD, Flux) that attempts to apply this manifest will fail in a reconciliation loop. If your operator manages critical infrastructure, this can cause a cascade where the desired state can never be reached.

2. Validating webhook has hardcoded logic (webhook code bug) The webhook's Go/Python validation handler explicitly checks if value <= 0 { deny }. A misconfigured Helm chart or an environment-specific override passes 0 for a field like minAvailable, terminationGracePeriodSeconds, or a custom threshold. Blast radius: Every kubectl apply, every Argo CD sync, every Helm upgrade for that resource class is blocked until the webhook is patched or the value is corrected.

Why this is dangerous beyond inconvenience: If the failurePolicy on the ValidatingWebhookConfiguration is set to Fail (the secure default), and your webhook pod crashes or becomes unreachable, all matching resource mutations cluster-wide are blocked. A misconfigured schema combined with a failing webhook pod is a cluster-level denial of service.

Prevention in CI/CD

1. Validate CRs against the CRD schema before kubectl apply using kubeconform:

# Install kubeconform
kubeconform -schema-location default \
  -schema-location 'https://raw.githubusercontent.com/datreeio/CRDs-catalog/main/{{.Group}}/{{.ResourceKind}}_{{.ResourceAPIVersion}}.json' \
  myresource.yaml

2. OPA/Gatekeeper ConstraintTemplate to enforce non-zero fields with context:

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: requirepositivereplicas
spec:
  crd:
    spec:
      names:
        kind: RequirePositiveReplicas
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package requirepositivereplicas
        violation[{"msg": msg}] {
          input.review.object.spec.replicas < 1
          msg := sprintf("replicas must be >= 1, got %v", [input.review.object.spec.replicas])
        }

3. Helm lint + schema validation in your pipeline:

# .github/workflows/validate.yaml
- name: Helm lint
  run: helm lint ./charts/myoperator --strict

- name: Kubeconform CRD validation
  run: |
    kubeconform -strict -summary ./manifests/

4. Set failurePolicy: Ignore only in dev namespaces. Never in production. A crashing webhook with failurePolicy: Fail will block all resource creation in matching namespaces.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: myoperator-validator
webhooks:
  - name: validate.myoperator.io
    failurePolicy: Fail   # Correct for prod
    namespaceSelector:
      matchExpressions:
        - key: environment
          operator: NotIn
          values: ["dev", "sandbox"]