The gap
docs/guide/addons.md (sso-gate → "SSO must ADD to your gateway's guards") tells a
user to run a kubectl get crd … -o jsonpath=… by hand to find out whether their
Envoy Gateway is new enough to understand SecurityPolicy.spec.mergeType:
$ kubectl get crd securitypolicies.gateway.envoyproxy.io -o jsonpath=\
'{.spec.versions[?(@.name=="v1alpha1")].schema.openAPIV3Schema.properties.spec.properties.mergeType.type}'
string # empty output = your Envoy Gateway is too old
That is a machine's job. If the field is missing, a server-side apply of the
sso-gate policy is rejected outright (.spec.mergeType: field not declared in schema) — and under GitOps that failure takes the whole sync with it. The user
finds out at apply time, not before.
Raised in the round-1 subagent review of #140 (finding 8).
What to build
A cluster-touching preflight — most naturally in lo doctor, which already has a
per-domain section — that, when sso-gate is in spec.bootstrap:
- resolves the target cluster,
- reads
securitypolicies.gateway.envoyproxy.io and checks that the served
schema declares spec.mergeType,
- fails with the remediation (upgrade
envoy-gateway to v1.8.0+ first, then
reconcile the policy) rather than printing a jsonpath for a human to run.
Generalise if it is cheap: the same shape ("this addon needs a CRD field the
installed CRD may not have") recurs whenever an addon manifest outruns its
chart pin.
Already covered, so out of scope here
- The static half is done:
tests/unit/sso_gate_merge_test.bats gates the
chart pin against the mergeType floor in CI, and lo audit's
exposed-endpoints check now flags a gateway-wide default-Deny that a
route-level policy without mergeType silently overrides
(audit::_secpol_scan).
- What is missing is only the live-cluster capability check.
Done when
lo doctor reports the mergeType capability of the target cluster's Envoy
Gateway CRD, with a unit test covering both the supported and unsupported CRD
shapes, and docs/guide/addons.md points at the command instead of the raw
jsonpath.
The gap
docs/guide/addons.md(sso-gate → "SSO must ADD to your gateway's guards") tells auser to run a
kubectl get crd … -o jsonpath=…by hand to find out whether theirEnvoy Gateway is new enough to understand
SecurityPolicy.spec.mergeType:That is a machine's job. If the field is missing, a server-side apply of the
sso-gatepolicy is rejected outright (.spec.mergeType: field not declared in schema) — and under GitOps that failure takes the whole sync with it. The userfinds out at apply time, not before.
Raised in the round-1 subagent review of #140 (finding 8).
What to build
A cluster-touching preflight — most naturally in
lo doctor, which already has aper-domain section — that, when
sso-gateis inspec.bootstrap:securitypolicies.gateway.envoyproxy.ioand checks that the servedschema declares
spec.mergeType,envoy-gatewayto v1.8.0+ first, thenreconcile the policy) rather than printing a jsonpath for a human to run.
Generalise if it is cheap: the same shape ("this addon needs a CRD field the
installed CRD may not have") recurs whenever an addon manifest outruns its
chart pin.
Already covered, so out of scope here
tests/unit/sso_gate_merge_test.batsgates thechart pin against the
mergeTypefloor in CI, andlo audit'sexposed-endpointscheck now flags a gateway-wide default-Deny that aroute-level policy without
mergeTypesilently overrides(
audit::_secpol_scan).Done when
lo doctorreports the mergeType capability of the target cluster's EnvoyGateway CRD, with a unit test covering both the supported and unsupported CRD
shapes, and
docs/guide/addons.mdpoints at the command instead of the rawjsonpath.