IpAllowPolicy is not applied when using passthrough mode and tcpproxy

[therealak12]

What steps did you take and what happened:

Create an httpproxy with passthrough: true and tcpproxy set. Then try to access the host (example.com here) from an IP not included in the ipAllowPolicy. It's still accessible.

An example of such httpproxy:

apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
  name: example.com
  namespace: playground
spec:
  tcpproxy:
    services:
    - name: sample-server
      port: 8000
      weight: 100
  virtualhost:
    fqdn: example.com
    ipAllowPolicy:
    - cidr: 10.20.16.0/22
      source: Peer
    tls:
      passthrough: true

What did you expect to happen: The host should only be accessible from the source IPs specified in the ipAllowPolicy list.

Anything else you would like to add: This might be the cause:

• Contour correctly processes and sets the ipAllowFilterPolicy configured on the virtual host.
• However, it doesn't call the VirtualHostsAndRoutes function (which calls the ipFilterConfig).
• It's because the VirtualHosts without routes are ignored in the loop.

I was wondering what's the reasoning behind this continue statement. Omitting this continue statement might resolve the issue.

Environment:

• Contour version: v1.25
• Kubernetes version: (use kubectl version): 1.23.3
• Kubernetes installer & version: Openshift installer
• Cloud provider or hardware configuration: hp g9 & g10
• OS (e.g. from /etc/os-release): fcos

[therealak12]

In not applying a configuration, this might be related to #2702 in which the OP says

With that said, it seems like there might be another issue where the TLS configuration is not being applied properly in this scenario.

[therealak12]

Related issue: #2855

[Bilanda]

Any news about this issue ?

It looks like even without passthrough, ipAllowPolicy is still not used with tcpproxy mode.

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[therealak12]

/remove-lifecycle stale

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack

[github-actions[bot]]

The Contour project currently lacks enough contributors to adequately respond to all Issues.

This bot triages Issues according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, the Issue is closed

You can:

• Mark this Issue as fresh by commenting
• Close this Issue
• Offer to help out with triage

Please send feedback to the #contour channel in the Kubernetes Slack