[Question] Anyway to do L4 ip filtering on HTTPRoute?

[LeeTeng2001]

Description:
Right now an invalid request will go through L7 filter chain and return RBAC error at the end, it would be preferable to just drop the packet based on incoming packet ip, maybe there's something that I missed?
Is this a gateway API limitation?

Right now I'm using a SecurityPolicy like this:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: xx-whitelist-http-client-ip
  namespace: envoy-gateway-system
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: xx-gateway
      sectionName: xxx 
  authorization:
    defaultAction: Deny
    rules:
      - action: Allow
        principal:
          clientCIDRs:
            - 1.1.1.1/32

[arkodg]

+1 , I see value in adding this, maybe part of this feature/API could be introduced in CTP, and we alredy have the underlying code to perform this in the network rbac filter
wdyt @envoyproxy/gateway-maintainers

[rudrakhp]

+1

[LeeTeng2001]

bump for discussion, I'm open to work on this feature

[LeeTeng2001]

I've poked around with the source code and envoyproxy source code, seems like L4 filtering is currently not supported even with plain EnvoyProxy? Relevant issue: envoyproxy/envoy#29822

[arkodg]

@LeeTeng2001 check https://github.com/envoyproxy/gateway/blob/main/internal/xds/translator/authorization_tcp.go
the TODO is the API in CTP and plumbing it

[zhaohuabing]

+1 adding this to CTP

The API could be something like an IP AllowList/DenyList

[arkodg]

discussed this in the community meeting today, @nareddyt had a good suggestion, to add a type to differentiate Peer vs Remote / Client IPs within SecurityPolicy to achieve the same thing instead of adding a new API, +1 from me

[LeeTeng2001]

So I just add a new Auth method in SecurityPolicySpec? Or reuse authorization?

I think a new action is sufficient ?

  authorization:
    defaultAction: Drop
    rules:
      - action: Allow
        principal:
          clientCIDRs:
            - 1.1.1.1/32

[zhaohuabing]

Maybe we could add a new principal type here. I'm not great at naming, but just to help kick off the discussion here:

• directCIDRs
• downstreamCIDRs

[arkodg]

yeah ^ approach can work, we just need a better name imo :)

[nareddyt]

For naming inspiration, here is the Envoy network filter API. They call it remoteAddress (can be set via proxy protocol filter or XFF) vs directRemoteAddress (the L4 IP)

https://github.com/envoyproxy/envoy/blob/b8ef4ca4f710ab424a228ff7d68eb90171758d51/envoy/network/socket.h#L247-L256

[arkodg]

yah directClientCIDRs or just sourceCIDRs (align with TCP terminology) could work as well here