Proposal: Support ingress rule matching for bastion mode #1244
+259
−96
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
. IfbastionMode
is set to true, and ahostname
andservice
name are provided as part of the ingress rules config, then we attempt to match thehostname
against the headerCf-Access-Jump-Destination
in the incoming HTTP request. If theRule
matches, then we accordingly proxy the bastion request to the mentionedservice
. If a request does not match any service, then it falls into the usual catch-all behavior.I have tested this setup in our environment, and it works as expected. That said, I'd like to propose this as a feature request for the project. 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
#1243