💡Option to disable remote configuration of a Tunnel

[AlbertSPedersen]

When cloudflared establishes a connection to Cloudflare's edge, the origintunnel service sends the remote configuration to cloudflared (if available), and cloudflared happily applies it without a second thought, overwriting the local configuration.

As I will explain below, this can be a problem in some cases. Therefore I propose adding an option to cloudflared that disables remote configuration of a Tunnel.

Locally managed Tunnels

With a locally managed Tunnel, WARP-routing is disabled by default and must be explicitly enabled by adding the following keys to the configuration file.

warp-routing:
  enabled: true

From what I can can tell, having to explicitly enable warp-routing is meant as a security feature. In the event of a Cloudflare account compromise, even if an attacker has access to modify the network routing configuration of the ZT organization, they will be unable to turn the Tunnel into a "jump host" for its private network.

The Problem: Tunnel Migration

The problem is that, from what I can tell, it is not currently possible to tell cloudflared to ignore the remote configuration.

This means that, even if your Tunnel is locally managed and has WARP-routing disabled, in the event of a Cloudflare account compromise (or a vulnerability in Cloudflare), an attacker can simply convert the locally managed Tunnel to a remotely managed Tunnel and then enable WARP-routing.

While Cloudflare account compromise is unlikely if proper security is in place, it should be possible to take steps to prevent lateral movement in the unfortunate event that it does happen.

[joliveirinha]

@AlbertSPedersen what do you mean by: "his means that, even if your Tunnel is locally managed and has WARP-routing disabled, in the event of a Cloudflare account compromise (or a vulnerability in Cloudflare)" ?

if your tunnel is locally managed, then it is not remotely managed. Meaning that our services will not push the configuration to cloudflared.

Are you sure you are creating locally managed tunnels?

[AlbertSPedersen]

@joliveirinha The issue is that a locally managed Tunnel can be converted to a remotely managed Tunnel from the Zero Trust dashboard, and cloudflared then immediately applies the new configuration (which is now managed from the dashboard).

In the event of account compromise, the attacker can simply convert the locally managed Tunnel into a remotely managed Tunnel. With the ability to modify the configuration of the Tunnel, cloudflared can be made an entrypoint/jump host for the local network, allowing an attacker to gain more access. It is currently not possible to prevent this as far as I can tell.

[jeremydonahue]

I up-thumbed this issue, but also wanted to add that it would be nice if there was a way to convert a remotely managed tunnel back to a locally managed tunnel. All it takes is one well intentioned person to hit the Configure button in the Zero Trust dashboard, and now all local configuration is ignored for the tunnel and the service stops working. The only solution that I know of right now is to delete and recreate the tunnel. We prefer locally managed tunnels for the ability to manage the configuration with Git and pretty much never want remotely managed tunnels to be used.

[tjb900]

The issue is that a locally managed Tunnel can be converted to a remotely managed Tunnel from the Zero Trust dashboard, and cloudflared then immediately applies the new configuration (which is now managed from the dashboard).

The closing of #1086 combined with the lack of acknowledgement of this critial point is quite disappointing.