feat(gatewayapi): mount operator trust bundle on envoy-gateway and envoy-proxy#4796
Open
electricjesus wants to merge 2 commits into
Open
feat(gatewayapi): mount operator trust bundle on envoy-gateway and envoy-proxy#4796electricjesus wants to merge 2 commits into
electricjesus wants to merge 2 commits into
Conversation
…voy-proxy Envoy-gateway pulls wasm OCI images and may originate TLS to public upstreams (JWT/OIDC providers, tracing exporters, HTTPS clusters), but calico/base ships no public CA roots, leading to "x509: certificate signed by unknown authority" on every outbound TLS handshake. Operator already extracts the public CA bundle from its UBI base at build time and exposes it via certificatemanagement.TrustedBundle -- the same pattern used by intrusion-detection, log-collector, authentication, and core (calico-node, typha). The gateway-api render path simply did not consume it. Build a TrustedBundleWithSystemRootCertificates in the gateway-api reconciler and mount the resulting tigera-ca-bundle ConfigMap on both the envoy-gateway controller deployment and every provisioned envoy- proxy pod (Deployment + DaemonSet variants) at /etc/pki/tls/certs -- the path Envoy reads via SSL_CERT_DIR.
The FV suite runs only the GatewayAPI controller via setupManagerNoControllers, so nothing creates the tigera-operator/tigera-ca-private secret. The new CreateTrustedBundleWithSystemRootCertificates path in the gatewayapi controller now fails with 'CA secret does not exist yet and is not allowed for this call', which blocks GatewayClass rendering and times out 4 specs after 10s. Mirror the unit-test setup: call certificatemanager.Create with AllowCACreation and create the resulting Secret in tigera-operator, tolerating AlreadyExists across runs.
rene-dekker
reviewed
May 13, 2026
| return append(volumes, v) | ||
| } | ||
|
|
||
| func appendVolumeMountsIfMissing(mounts []corev1.VolumeMount, toAdd []corev1.VolumeMount) []corev1.VolumeMount { |
Member
There was a problem hiding this comment.
Can we do without this func and simply append? The overrides would still be called after this is called anyway.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds public-CA roots (extracted from operator's UBI base) + Calico CA to a
tigera-ca-bundleConfigMap in thetigera-gatewaynamespace, mounts it on the envoy-gateway controller Deployment and on every provisioned envoy-proxy pod (Deployment + DaemonSet variants) at/etc/pki/tls/certs. Uses the existingcertificatemanager.CreateTrustedBundleWithSystemRootCertificates()pattern already consumed by intrusion-detection, log-collector, authentication, and core.Type: bug fix / enhancement (gateway-api render path)
Components affected:
pkg/render/gatewayapi,pkg/controller/gatewayapiWhy
Envoy-gateway pulls wasm OCI images and may originate TLS to public upstreams (JWT/OIDC providers, tracing exporters, HTTPS clusters), but calico/base ships no public CA roots. Result:
x509: certificate signed by unknown authorityon every outbound TLS handshake from envoy-gateway / envoy-proxy.Per @hjiawei in Slack:
Confirmed:
build/Dockerfile:17,23copies/etc/pkifromubi9/ubi-minimalinto the operator image, andpkg/tls/certificatemanagement/certificatebundle.go:249-273reads it at runtime viagetSystemCertificates()and packages it for downstream components. The gateway-api render path was the only major component not consuming this.What this replaces
Supersedes the image-side workaround in tigera/calico-private#11876 (baking CA roots into envoy-gateway + envoy-proxy images directly). With this operator change, the image change is no longer needed. Same logic applies to the Istio sibling PR tigera/calico-private#11878.
Test plan
go build ./...(excluding pre-existing istio embed failure)go vet ./...go test ./pkg/render/gatewayapi/...— 20/20 specs (new positive test asserts ConfigMap + mount paths on both controller and proxy)go test ./pkg/controller/gatewayapi/...— green (BeforeEach now seeds the operator CA secret, mirroring the compliance controller test pattern)tigera-ca-bundleexists intigera-gateway, envoy-gateway and envoy-proxy pods have the volume mounted at/etc/pki/tls/certs, outbound TLS from envoy-gateway (wasm OCI fetch) succeeds withoutx509: unknown authorityRelease Note
For PR author
make gen-filesmake gen-versionsFor PR reviewers
A note for code reviewers - all pull requests must have the following:
kind/bugif this is a bugfix.kind/enhancementif this is a a new feature.enterpriseif this PR applies to Calico Enterprise only.