Cloudflared gRPC
You set up cloudflared grpc by routing HTTP/2 traffic through a private tunnel to your backend service. You must turn on HTTP/2 origin support and use TLS so gRPC frames stay intact. Teams often build this tunnel to expose internal services without opening public firewall ports. Still, once a user or service passes the edge check, they often get broad reach. A single tunnel role can let someone call any method on that backend server. How cloudflared grpc routing works in practice A gRPC call
gRPC Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up cloudflared grpc by routing HTTP/2 traffic through a private tunnel to your backend service. You must turn on HTTP/2 origin support and use TLS so gRPC frames stay intact. Teams often build this tunnel to expose internal services without opening public firewall ports. Still, once a user or service passes the edge check, they often get broad reach. A single tunnel role can let someone call any method on that backend server.
How cloudflared grpc routing works in practice
A gRPC call needs end-to-end HTTP/2 support to send binary data and stream messages. Standard web tunnels often downgrade traffic to HTTP/1.1 at the edge, which breaks gRPC streams. To make cloudflared grpc work, the tunnel daemon must keep an active HTTP/2 link to your origin. You start by running the daemon inside your private network near your backend app.
The daemon opens outbound links to the edge network so you avoid inbound firewall holes. Next, you point a public hostname at the local port where your gRPC server listens. You must set the origin protocol to use HTTP/2 and present a valid TLS certificate. The edge network then accepts incoming gRPC calls and forwards the raw HTTP/2 frames down the tunnel. Your local daemon hands those frames to the backend service over the local network.
Managing identity and service tokens at the edge
Most teams pair their tunnel with edge login rules to block unknown traffic. You can require users or bots to present a service token or identity header first. The edge checks this token before any packet enters the private tunnel. If the token is valid, the edge forwards the request to your internal daemon.
Teams often share one service token across many test scripts or developer machines. When a developer needs to test a gRPC method, they grab the shared token. They also might run a local daemon wrap command to bridge their laptop to the private network. This approach gets traffic flowing fast, but it creates a large blind spot for security teams. Everyone with that token shares the exact same network trust level.
gRPC Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What the native setup solves and what it misses
The native tunnel setup solves the problem of public port exposure very well. Your backend server stays hidden behind a private firewall with no public IP address. The edge blocks unauthenticated network scans and drops bad traffic before it hits your servers. It also handles TLS termination and keeps the transport path encrypted across the open internet.
Still, the native setup only decides who can open the network pipe. Once a session passes the edge check, the tunnel acts as a blind pipe for HTTP/2 frames. It does not check which specific gRPC service or method a user calls inside that stream. A developer who only needs to read status data can also trigger a delete method. Also, your edge logs only show basic network metadata rather than the payload details. If a response contains customer emails, phone numbers, or card numbers, that raw data flows right through. Masking rules that rewrite matched fields in results do not exist in a basic network tunnel.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why do my gRPC calls fail through a standard web tunnel?
Standard tunnels often downgrade origin traffic to HTTP/1.1 by default. Because gRPC requires HTTP/2 framing and trailers, you must enable HTTP/2 to the origin.
Does the backend server need a TLS certificate for gRPC?
Yes, the tunnel daemon expects a TLS connection when sending HTTP/2 traffic to your local origin. You can use a private certificate and tell the daemon to trust your local authority.
Can edge rules restrict specific gRPC methods on a single port?
Edge rules work best at the hostname and network connection level. Controlling individual gRPC methods or inspecting message payloads requires deeper control closer to the service.