This note records the Helm pain surfaced during catalog review and where the current ConfigHub/cub installer proof absorbs it.
Support Boundary
| Field | Value |
|---|---|
| Catalog status | catalog-supported |
| Support level | supported-for-declared-scopes |
| Supported scopes | local-test |
| Production readiness | production-review-ready |
| Variants in this note | default, crds-enabled |
Production support is not implied by this file. A chart can be supported for local proof/demo use while still needing accepted scan, gate, lifecycle, and operating-policy dispositions plus a final target-scoped support decision.
Chart Notes
- Default chart does not render CRDs because crds.enabled defaults to false.
- crds-enabled variant renders six cert-manager CRDs as ordinary rendered objects.
- startup API check is a Helm post-install hook and is excluded from the rendered revision by --no-hooks.
- Mutating and validating webhook readiness must be observed after apply because rendered objects alone do not prove webhook health.
- A stricter cub-scout live witness on kind Kubernetes 1.30 found that four rendered CRDs contain spec.versions[0].selectableFields that the live API omitted after apply; workloads converged, but this blocks strict rendered-object/live parity for that target profile.
- extraObjects is a tpl-powered extension slot; promoted variants keep it empty.
Catalog Mitigations
- Supported for local-test and proof-demo usage through real cub installer and ConfigHub receipts.
- default preserves the normal cert-manager controller/webhook install shape.
- crds-enabled is supported when CRD lifecycle ownership is intentionally accepted for the local-test scope.
- CRD lifecycle, webhook readiness, startup API hook routing, cluster RBAC, extension slots, and scan/gate warnings are recorded as production review input.
- Production recommendation remains a separate decision; crds-enabled is the stronger first production-review path, while default requires compatible CRDs to be staged and observed in the target cluster.
Control Points
| Control point | Status | Mitigation / evidence | |||
|---|---|---|---|---|---|
| source-lock | handled | source-lock.yaml | |||
| dependency-lock | handled | chart has no subchart dependencies | |||
| capability-profile | handled | render is bound to the named Kubernetes capability profile even though this chart version does not branch on .Capabilities. | |||
| capability-profile-live-pruning | strict-live-object-parity-blocked-on-kubernetes-1.30 | cub-scout live witness on kind Kubernetes 1.30 found four rendered CRDs with spec.versions[0].selectableFields that were absent from the live CRDs after apply; workloads converged, but strict rendered-object/live parity is blocked until the capability/feature-gate route is decided. | |||
| crd-policy | variant-controlled | CRDs are ordinary rendered objects only in the crds-enabled variant and still need lifecycle/upgrade policy. | |||
| hook-policy | handled-for-render | startup API check Job is a Helm post-install hook and is excluded from the render proof; lifecycle policy must handle it before production. | |||
| admission-webhook | scan-and-observe | recorded in control-points.yaml | |||
| cluster-rbac | scan-and-review | scan receipts | |||
| tpl | controlled-by-empty-defaults | extraObjects uses tpl; promoted variants do not set that value. | |||
| installer-support-object | handled | v1\ | Namespace\ | \ | cert-manager |
Control Point Index
- admission-webhook
- admission-webhook-observation
- capability-profile
- capability-profile-live-pruning
- cluster-rbac
- cluster-rbac-scan
- crd-lifecycle-policy
- crd-policy
- dependency-lock
- hook-lifecycle-policy
- hook-policy
- installer-support-object
- source-lock
- tpl
- tpl-extension-slot
Proof Links
- Catalog map: CATALOG.md
- Machine index: artifact-index.yaml
- Helm plan: helm-plan.yaml
- Control points: control-points.yaml
- Chart dossier: chart-dossier.yaml