Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

💡Support ingress rule matching for bastion mode #1243

Open
shayonj opened this issue May 10, 2024 · 0 comments
Open

💡Support ingress rule matching for bastion mode #1243

shayonj opened this issue May 10, 2024 · 0 comments
Labels
Priority: Normal Minor issue impacting one or more users Type: Feature Request A big idea that would be split into smaller pieces

Comments

@shayonj
Copy link

shayonj commented May 10, 2024

Describe the feature you'd like
Be able to support ingress rules in bastion Mode

Context

👋🏾 Hello from Tines! I work on the Platform Team, and we're big fans and heavy users of CF Tunnel. In a nutshell, we use Tunnel in our multi-tenant environment to proxy our customers' HTTP workloads from our cloud instances to their on-prem/self-hosted instances through Cloudflared Tunnel. We've built a small orchestration layer on top of the Tunnel that dynamically proxies our customers' requests from our HTTP client middleware via cloudflared access (entry node) to the customers' network (exit node).

Our setup operates in bastion mode, meaning the proxied request has a single destination.

Problem

We are looking to eliminate any possibility of "data exfiltration." As you might guess, the exit node where the cloudflared tunnel runs can access virtually any service within its network boundary.

Tunnel Ingress Rules is an excellent feature that allows traffic routing to different services based on hostname. It also enables "blackhole-ing" incoming requests that do not match a certain hostname by declaring http_status:404 as the service, for example.

However, ingress rules do not work with bastionMode. We could avoid using bastion mode, but given the scale (many multi tenant clusters) and dynamism of how we run Tunnels, this would require us to provision a new hostname/DNS per Tunnel in a multi-tenant env to leverage ingress rules in non-bastion mode, further necessitating some UX/DX changes.

Proposal

My proposal is to extend the existing functionality of bastionMode. If bastionMode is set to true, and a hostname and service name are provided as part of the ingress rules config, then we attempt to match the hostname against the header Cf-Access-Jump-Destination in the incoming HTTP request. If the Rule matches, then we accordingly proxy the bastion request to the mentioned service. If a request does not match any service, then it falls into the usual catch-all behavior.

Describe alternatives you've considered
Mentioned above

Additional context
I wanted to see if this is something thats possible and how much lift would it be. I was able to try this out in our setup and works as expected. So, I took a stab at a PR here: #1244

I would also love to learn if there are opportunities to improve this approach or consider other options.

Given our reliance on Tunnel, we would also be happy to discuss what continued support and maintenance would look like.

Example config

tunnel: aaaa-bbbb-cccc

ingress:
  - hostname: test-foobar-service.com
    service: http_status:200
  - hostname: "foobar.tunnel-dev.com"
    service: "http://localhost:9000"
  - hostname: "foobar1.tunnel-dev.com"
    service: "http://localhost:9002"
    originRequest:
      bastionMode: true
  - service: http_status:404

Thank you!

@shayonj shayonj added Priority: Normal Minor issue impacting one or more users Type: Feature Request A big idea that would be split into smaller pieces labels May 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Priority: Normal Minor issue impacting one or more users Type: Feature Request A big idea that would be split into smaller pieces
Projects
None yet
Development

No branches or pull requests

1 participant