Enforce HTTP Intent at a Destination Waypoint

Enterprise problem: Connection-level permission cannot distinguish “generate an artifact” from “delete a runtime,” so an allowed caller may still perform an unsafe HTTP action. Whole-course context: The incoming ambient-l4-local gate authenticates direct ServiceAccount connections and has live positive/denied evidence, but it deliberately has no waypoint or HTTP policy. Today’s slice: Applying full ambient-local adds the destination waypoint, selects it on the namespace, rewrites all five L4 destinations to accept only the waypoint principal, and adds four exact targetRefs L7 policies. Gateway API supplies the waypoint Gateway, but this repository declares no HTTPRoute, so no traffic split or rewrite is claimed. End-of-day evidence: Accepted/Programmed waypoint, waypoint-only L4 rewrite, exact L7 policies, verifier-executed POST success, verifier-executed GET 403, no-HTTPRoute check, environment, time, run, and trace prove the boundary. Still unsolved: Migration, telemetry, failure recovery, rollback, and EKS ownership follow next.

The customer outcome is a reviewable enforce http intent at a destination waypoint change, not a collection of requirements. This day starts with the implementation boundary, then uses the command or manifest below to produce positive, denied, and recovery evidence.

Waypoint proxy, Istio authorization policy controller, ServiceAccounts, and destination API; waypoint and application pods; Kubernetes etcd and access logs/traces; cache: not involved.

This map names the implementation boundary for this day. The service or controller changes only the state it owns; runtime and audit evidence let the operator distinguish a declared change from an effective one.

Declare the destination waypoint and L7 policy

A waypoint name alone does nothing, so the exact Gateway, namespace selection, and Service-targeted policy must agree.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: forge-waypoint
  namespace: helixworks-forge
  labels:
    istio.io/waypoint-for: service
spec:
  gatewayClassName: istio-waypoint
  listeners:
    - name: mesh
      port: 15008
      protocol: HBONE

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: generator-from-control-plane
  namespace: helixworks-forge
spec:
  targetRefs: [{ group: "", kind: Service, name: generator }]
  action: ALLOW
  rules:
    - from: [{ source: { principals: [cluster.local/ns/helixworks-forge/sa/control-plane] } }]
      to: [{ operation: { methods: [POST], paths: [/generate] } }]

These excerpts are byte-exact from gitops/apps/forge/mesh/ambient-l7/waypoint.yaml and authorization.yaml. The component also patches all five L4 boundaries to the forge-waypoint principal and defines destination policies for runtime, evidence, and broker; it defines no HTTPRoute.

Gateway readiness does not prove HTTP authorization or routing, so inspect all three claims independently.

: "${MESH_CONTEXT:?set the exact kubectl context}"
kubectl --context "$MESH_CONTEXT" apply -k gitops/apps/forge/overlays/ambient-local
MESH_CONTEXT="$MESH_CONTEXT" ./scripts/verify-istio-ambient.sh l7
kubectl --context "$MESH_CONTEXT" -n helixworks-forge wait gateway/forge-waypoint --for=condition=Programmed --timeout=180s
kubectl --context "$MESH_CONTEXT" -n helixworks-forge get authorizationpolicy generator-from-control-plane runtime-from-control-plane evidence-from-control-plane broker-from-publishers
if kubectl --context "$MESH_CONTEXT" -n helixworks-forge get httproute -o name | grep -q .; then
  echo "route veto: implementation unexpectedly contains HTTPRoute desired state" >&2
  exit 1
fi

The scoped repository verifier is executable evidence, not an instruction comment: it checks enrollment and L4 prerequisites, requires the namespace waypoint label, waits for Gateway Accepted/Programmed and waypoint rollout, verifies all four targetRef policies, then sends authenticated POST /generate and requires a generated artifact. It immediately sends GET /generate from the same control-plane workload and accepts only HTTP 403. A successful kubectl get without these requests is not L7 proof.

Gateway API’s HTTPRoute resource models HTTP routing rules, but installing its CRD or creating a Gateway does not create a route (Gateway API HTTPRoute).

L4 identity previously answered only whether the control plane could connect, leaving every HTTP operation equally reachable. The waypoint now permits specific destination methods and paths while routing remains explicitly undeclared.

The waypoint is an L7 enforcement point; it is not itself an HTTP routing policy.

• Attach ambient L7 policy to destination Services with targetRefs.
• Prove both allowed and denied HTTP operations using the same authenticated caller.
• Claim route behavior only when an HTTPRoute exists in Git, is Accepted, and changes observed requests.

L7 policy is ready only when attachment, behavior, and absence claims are independently verified.

• [ ] Gateway Accepted and Programmed with namespace selection recorded
• [ ] Full ambient-local replaces the Day 32 direct L4 principals with waypoint-only L4 principals
• [ ] Four exact Service-targeted policies reconciled
• [ ] Repository L7 verifier executes allowed POST and requires wrong-method GET 403
• [ ] Zero HTTPRoute desired/live state recorded; no routing outcome claimed