ValidatingAdmissionPolicy in charts/crds/crds/ (Helm CRD dir) breaks external CRD management tools

[p-zany]

If you are reporting any crash or any potential security issue, do not
open an issue in this repo. Please report the issue via emailing
envoy-gateway-security@googlegroups.com where the issue will be triaged appropriately.

Description:

Since v1.8.0, the gateway-helm chart bundles ValidatingAdmissionPolicy and ValidatingAdmissionPolicyBinding resources (safe-upgrades.gateway.networking.k8s.io) inside charts/crds/crds/gatewayapi-crds.yaml — which is the crds/ directory of the crds sub-chart.

Helm treats crds/ as a special directory for CustomResourceDefinition objects only. Placing non-CRD resources there causes breakage in tools that process chart CRD directories, such as the Flux helm-controller's crds: CreateReplace strategy, which fails with:

failed to apply CustomResourceDefinitions: failed to update CustomResourceDefinition(s):
no ValidatingAdmissionPolicy with the name "safe-upgrades.gateway.networking.k8s.io" found

The same resources already appear correctly in charts/gateway-crds-helm/templates/standard-gatewayapi-crds.yaml (inside templates/), suggesting the placement in crds/ may be unintentional.

Repro steps:

1. Use Flux with a HelmRelease pointing to oci://docker.io/envoyproxy/gateway-helm with version: "*" and crds: CreateReplace
2. When chart resolves to v1.8.0, install fails immediately with the error above
3. The ValidatingAdmissionPolicy does not exist yet in the cluster (first install or fresh cluster)

Environment:

• Gateway version: v1.8.0 (gateway-helm chart 1.8.0)
• Kubernetes: v1.32.7

Logs:

Helm install failed for release infrastructure/envoy-gateway with chart gateway-helm@1.8.0:
failed to apply CustomResourceDefinitions: failed to update CustomResourceDefinition(s):
no ValidatingAdmissionPolicy with the name "safe-upgrades.gateway.networking.k8s.io" found

Suggested fix:

Move ValidatingAdmissionPolicy / ValidatingAdmissionPolicyBinding from charts/crds/crds/gatewayapi-crds.yaml to templates/ (as is already done in charts/gateway-crds-helm/templates/), so the crds/ directory contains only CustomResourceDefinition objects.

Related Flux issue: fluxcd/helm-controller#1486

[matheuscscp]

Here's an example of how to split off VAP from crds/ and move it to templates/:

• CRDs under crds/: https://github.com/matheuscscp/cloudflare-gateway-controller/blob/main/charts/cloudflare-gateway-controller/crds/gateway-api.yaml
• VAP under templates/: https://github.com/matheuscscp/cloudflare-gateway-controller/blob/main/charts/cloudflare-gateway-controller/templates/gateway-api.yaml
• How to disable: https://github.com/matheuscscp/cloudflare-gateway-controller/blob/main/charts/cloudflare-gateway-controller/README.md
• Automation for the split: https://github.com/matheuscscp/cloudflare-gateway-controller/blob/main/.github/workflows/upgrade-gateway-api.yaml

[arkodg]

thanks for flagging this and as well as sharing the pointers to split the upstream YAML !
@zhaohuabing @zirain we'll probably need to do something similar for gateway-helm using bash & make in

gateway/tools/make/kube.mk

Line 103 in 2b3cf6c

generate-gwapi-manifests: ## Generate Gateway API manifests and make it consistent with the go mod version.

Workaround for users reaching here until this issue is resolved - please rely on the gateway-crds-helm helm chart for CRDs and the VAP, and skip installing CRDs from the gateway-helm chart

[matheuscscp]

Note: Unfortunately, the alternative chart gateway-crds-helm cannot be used with Flux helm-controller. It places all the CRDs under templates/, and this blows up the Helm storage.

---

We are shipping a fix next week that ignores non-CRDs under crds/ and prints a loud warning log, this should unblock users from installing the main things but the VAP + binding will be missing until this chart is fixed:

fluxcd/helm-controller#1486 (comment)