You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Seamlessly expose TCP/UDP* services from one cluster to another securely tunnelled over Cloudflare.
Current status
Currently, the operator provides the tunnelling functionality of cloudflared to expose services. This is good enough for HTTP/S endpoints. But for any TCP/UDP* (including SSH/RDP) based traffic, like a database service, this is one piece of the puzzle. There needs to be another cloudflared running at the consumer pointing to the same FQDN which in turn would expose a port that connects to the other end.
Implementation
Implementing this would be a two-step process.
We need another set of annotations for the service. If the endpoint is protected by Cloudflare Access/Zero Trust, we need a CRD that can capture data needed for logging in and getting a token (which would not need the level of access used by the tunnel)
The service controller would then listen to those, spin up a cloudflared deployment in access mode and point the service to it. An alternative could be to run a common WARP client per CRD, but that would be getting more access than needed, creating edge cases for conflicting ports, and a security nightmare.
The text was updated successfully, but these errors were encountered:
Motivation
Seamlessly expose TCP/UDP* services from one cluster to another securely tunnelled over Cloudflare.
Current status
Currently, the operator provides the tunnelling functionality of cloudflared to expose services. This is good enough for HTTP/S endpoints. But for any TCP/UDP* (including SSH/RDP) based traffic, like a database service, this is one piece of the puzzle. There needs to be another cloudflared running at the consumer pointing to the same FQDN which in turn would expose a port that connects to the other end.
Implementation
Implementing this would be a two-step process.
We need another set of annotations for the service. If the endpoint is protected by Cloudflare Access/Zero Trust, we need a CRD that can capture data needed for logging in and getting a token (which would not need the level of access used by the tunnel)
The service controller would then listen to those, spin up a cloudflared deployment in access mode and point the service to it. An alternative could be to run a common WARP client per CRD, but that would be getting more access than needed, creating edge cases for conflicting ports, and a security nightmare.
The text was updated successfully, but these errors were encountered: