Enforce HTTP Intent at a Destination Waypoint

This course is built around the public Zheta Kubernetes Lab monorepo. The excerpt below is runnable source, not pseudocode.

Source: gitops/apps/forge/mesh/ambient-l7/authorization.yaml

spec:
  targetRefs: [{ group: "", kind: Service, name: generator }]
  action: ALLOW
  rules:
    - from: [{ source: { principals: [cluster.local/ns/zheta-forge/sa/control-plane] } }]
      to: [{ operation: { methods: [POST], paths: [/generate] } }]

Code to reality

Declared intent

Allow one authenticated control-plane HTTP operation at the generator destination waypoint.

Interpreter

Istiod attaches the targetRef policy to the destination waypoint, whose Envoy proxy parses method and path.

Software effect

POST /generate proceeds for the control-plane principal while other methods, paths, or principals do not match.

Hardware effect

The waypoint Pod spends node CPU and memory on HTTP parsing, authorization, telemetry, and forwarded network traffic.

Observable evidence

Gateway readiness, policy generation, allowed POST, wrong-method denial, and explicit HTTPRoute absence prove the claim.

The source tables below remain the detailed contract. Begin with these customer paths:

• D33-UC-01
  • Person: Enterprise builder
  • Job: Generate, publish, inspect evidence, and manage runtime through approved Forge APIs
  • Observable result: Control plane reaches only the declared Service methods and paths through the destination waypoint
• D33-UC-02
  • Person: Delivery operator
  • Job: Introduce destination HTTP policy without inventing traffic-management behavior
  • Observable result: Gateway is Accepted and Programmed; source contains exact targetRefs policies and no HTTPRoute

Now turn each customer job into a story with a result that an engineer can check:

• D33-US-01
  • Story: As an enterprise builder, I want control-plane calls limited by method and path, so that service identity does not imply every API action
  • Observable acceptance: Positive and denied traces identify source principal, target Service, method, path, policy generation, environment, and time
• D33-US-02
  • Story: As a delivery operator, I want routing claims tied to checked-in HTTPRoute source, so that a waypoint Gateway is not mistaken for customer traffic…
  • Observable acceptance: Review proves Gateway readiness, four L7 policies, zero HTTPRoute objects, source revision, and explicit routing veto

Finally trace each story through the system that owns its state and the evidence that proves the outcome:

• D33-FLOW-01
  • Trigger: Builder requests POST /generate through the control plane
  • Responsible systems: source ztunnel, forge-waypoint Gateway/Envoy, Istiod, generator/runtime/evidence/broker Services
  • Authoritative state: Git targetRefs policy plus Kubernetes Gateway and AuthorizationPolicy status; Forge stores own product result
  • Owned record: WaypointBinding
  • Observable evidence: Principal, Gateway UID, policy generation, method/path, response, environment, timestamp, run, and trace
  • Failure signal: Waypoint bypass, wrong targetRef, allowed forbidden method, or denied approved product request
• D33-FLOW-02
  • Trigger: Approved identity sends a forbidden method or reviewer claims route behavior
  • Responsible systems: Gateway API, Istiod Gateway controller, Argo/Kubernetes query, reviewer
  • Authoritative state: Git is desired-state authority; Kubernetes API is observed-state authority
  • Owned record: L7PolicyRevision
  • Observable evidence: HTTP 403, zero HTTPRoute claim, unaffected artifact response, source revision, environment, time, and test ID
  • Failure signal: Gateway not Accepted/Programmed, unexpected HTTPRoute, unsupported routing claim, or missing positive control

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.

Identity-only access is too broad when one service exposes several actions with different customer consequences.

An L7 rule can look precise yet attach to the wrong resource, so acceptance must prove both the target Service and the HTTP operation.

The customer-visible flow must survive policy, while a nearby unsafe action must fail for the intended L7 reason.

Ztunnel does not parse HTTP headers or methods, so the destination waypoint becomes the explicit L7 enforcement point.

HTTP authorization and routing are different desired-state records, so absence of an HTTPRoute is meaningful and must remain visible.

Generated-application database: Not created in this slice — existing generated-app data remains application-owned while mesh policy and evidence records govern only hosted-runtime traffic.

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: zheta-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: zheta-forge
spec:
  targetRefs: [{ group: "", kind: Service, name: generator }]
  action: ALLOW
  rules:
    - from: [{ source: { principals: [cluster.local/ns/zheta-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 zheta-forge wait gateway/forge-waypoint --for=condition=Programmed --timeout=180s
kubectl --context "$MESH_CONTEXT" -n zheta-forge get authorizationpolicy generator-from-control-plane runtime-from-control-plane evidence-from-control-plane broker-from-publishers
if kubectl --context "$MESH_CONTEXT" -n zheta-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