Skip to content

Fail-open behavior and incorrect status reporting for policy attachment errors #11402

@timflannagan

Description

@timflannagan

kgateway version

main

Kubernetes Version

N/A

Describe the bug

When a user configures a valid TrafficPolicy resource with correct targetRef values, the policy attaches and functions as expected. However, if the user later updates the targetRef field to point to a non-existent resource (e.g., a typo in the name), the policy silently detaches and stops applying the desired policy.

This results in a fail-open behavior:

  • Routes that were previously secured or modified by the policy are no longer protected
  • There is no visible indication in the policy or HTTPRoute status that the attachment has failed
  • The dataplane may return 200 OK to requests that were previously restricted

Expected Behavior

Policy attachment should follow fail-closed behavior here.

Steps to reproduce the bug

  1. make run
  2. apply basic GW resources
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: httpbin-gateway
  namespace: httpbin
spec:
  gatewayClassName: kgateway
  listeners:
    - protocol: HTTP
      port: 8080
      name: http
      allowedRoutes:
        namespaces:
          from: All
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-route
  namespace: httpbin
spec:
  parentRefs:
    - name: httpbin-gateway
  hostnames:
    - "www.example.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
      - name: httpbin
        port: 8000
---
apiVersion: gateway.kgateway.dev/v1alpha1
kind: TrafficPolicy
metadata:
  name: valid-transformation
  namespace: httpbin
spec:
  targetRefs:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: httpbin
  transformation:
    response:
      add:
      - name: x-foo
        value: bar
  1. Verify the policy status and HTTPRoute status' are accepted/resolved/etc.
  2. Update the resources and break the targetRefs attachment
  3. Verify the policy status is stale, look at the controller logs for the error message, etc
  4. Verify requests to the exposed route doesn't have the desired policy attached

Additional Environment Detail

N/A

Additional Context

N/A

Metadata

Metadata

Assignees

Type

Projects

Status

In progress

Relationships

None yet

Development

No branches or pull requests

Issue actions