dex: render the authcodes CustomResourceDefinition from templates

[danish9039]

The problem

Rendering the Dex chart with helm template produced no CustomResourceDefinition at all:

$ kustomize build common/dex/overlays/oauth2-proxy | grep -c 'kind: CustomResourceDefinition'
1
$ helm template dex common/dex/helm --namespace auth --include-crds | grep -c 'kind: CustomResourceDefinition'
1
$ helm template dex common/dex/helm --namespace auth | grep -c 'kind: CustomResourceDefinition'
0

authcodes.dex.coreos.com lived in the chart's crds/ directory, which Helm only installs with --include-crds. Rendering the chart and applying the output — a documented installation path — therefore installed a Dex that cannot store OAuth authorization codes.

Two further consequences of that directory:

• The definition is never upgraded. Helm's own documentation states there is "no support at this time for upgrading or deleting CRDs using Helm" (CRD best practices), so it keeps its first-installed schema permanently.
• It is invisible to --dry-run, so custom resources cannot be validated against it.

The change

The definition is now rendered from common/dex/helm/templates/crds.yaml, carrying helm.sh/resource-policy: keep, gated by crds.enabled (default true).

helm upgrade updates the schema; helm uninstall keeps the definition and the AuthCode objects. Set crds.enabled=false when an administrator manages CustomResourceDefinitions separately.

This deliberately deviates from Helm's published recommendation to use crds/, matching what applications/dashboard/helm already does for profiles.kubeflow.org and poddefaults.kubeflow.org. The chart README states the deviation and its reason.

Why the template is hand-written

scripts/synchronize-dex-manifests.sh previously copied the upstream file into the chart. A copied file cannot carry the retention annotation, so the chart copy is now hand-written — and two independent checks fail if it drifts from the upstream definition synchronized into common/dex/base/upstream/crds.yaml:

• the synchronization script runs the drift check and aborts before committing;
• tests/test_dex_helm_crd_lifecycle.py runs the same check in continuous integration.

Verified by deliberately changing singular: authcode in the template, which fails with:

common/dex/helm/templates/crds.yaml has drifted from the upstream
CustomResourceDefinition synchronized into common/dex/base/upstream/crds.yaml.

Making the fix stick

validate_helm_crd_resource_policies skips any component absent from EXPECTED_HELM_CRD_RESOURCE_POLICIES, which is why this regression passed the comparison unnoticed. Declaring dex turns it into enforcement — reverting the fix now fails the comparison:

Helm CRDs missing helm.sh/resource-policy=keep: authcodes.dex.coreos.com

Verification

$ python3 tests/test_dex_helm_crd_lifecycle.py
Ran 5 tests — OK
$ python3 -m unittest tests/test_helm_kustomize_compare.py
Ran 17 tests — OK
$ ./tests/helm_kustomize_compare_all.sh dex
SUCCESS: All scenarios passed for dex!
$ helm lint common/dex/helm --namespace auth
1 chart(s) linted, 0 chart(s) failed

Parity is unaffected: helm.sh/* annotations are normalized away on both sides, and the rendered resource set is unchanged.

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign juliusvonkohout for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment