Share Policies

Share Policies control access to the Share feature (inbound tunnels). They gate tunnel creation to users with specific IdP roles, and optionally restrict what traffic is allowed to traverse those tunnels.

Default behavior: deny everything. If no Share Policies are configured, no users can create tunnels regardless of their role.

Building Blocks

Share Policies are assembled from reusable building blocks, defined in order:

1. Networks

A Network is a named set of IP CIDR ranges representing a known network location — for example, your corporate office, a VPN, or a cloud VPC.

Name: Corporate Office
CIDRs: 203.0.113.0/24, 203.0.114.0/24

2. Header Rules

A Header Rule is a named set of HTTP header match conditions — for example, a valid webhook signature or a specific API key header.

Each condition specifies a header name and a match type:

Match type	Description
Exact	Header value equals the specified string
Prefix	Header value starts with the specified string
Contains	Header value contains the specified string
Regex	Header value matches the specified regular expression
Exists	Header is present (any value)

Multiple conditions within a Header Rule are combined with AND — all must match.

Name: Valid Stripe Signature
Conditions:
  - Stripe-Signature  Exists

3. Services

A Service is a registered local target (Name + Backend Target) that tunnels are permitted to expose. The Service Registry is the outer fence for which local endpoints a tunnel may point at, separate from who may create the tunnel.

Loopback targets bypass the registry. Non-loopback targets must resolve to a registered Service. See Services for the full model.

4. Share Rules

A Share Rule composes up to three independent conditions — a Service, a Network, and a Header Rule — into a single named entry. The conditions evaluate at two different moments:

• Service is checked at tunnel creation. It controls which target the user is allowed to point a tunnel at.
• Network and Header Rule are checked on inbound requests, after the tunnel is up. They control which traffic is allowed through the tunnel.

The Service field’s behavior is the most easily misread:

• No Service set → the rule grants loopback targets only (localhost, 127.0.0.1, [::1], 0.0.0.0, or any hostname the server resolves to a loopback IP — see Services). The rule does not permit any non-loopback target, even ones that happen to be in the Service Registry.
• A specific Service pinned → the rule grants exactly that one non-loopback Service, and no other.

There is no “any registered Service” wildcard. If a role needs access to multiple non-loopback Services, the policy needs one Share Rule per Service (or multiple policies).

Network and Header Rule fields filter inbound traffic on whatever tunnel the Service field permitted:

• A rule with only a Network matches requests from those CIDRs.
• A rule with only a Header Rule matches requests with those headers.
• A rule with both restricts to traffic matching the Network and the Header Rule.
• A rule with neither matches all inbound traffic on the granted target.

Conditions within a rule combine with AND — all set fields must be satisfied for the rule to fire.

5. Share Policies

A Share Policy ties one or more IdP roles to one or more Share Rules.

• Roles — which IdP roles this policy applies to (e.g., engineering, contractors)
• Rules — which Share Rules must be satisfied (OR semantics — any matching rule allows access)

When a user attempts to create a tunnel, all Share Policies matching their roles are evaluated. If any rule across any matching policy passes, access is granted.

Examples

Loopback-only policy with traffic filtering

Networks:
  "Corporate Office"  →  203.0.113.0/24
  "VPN"               →  10.8.0.0/16

Header Rules:
  "Stripe Webhook"    →  Stripe-Signature: Exists

Share Rules:
  "From Office"       →  Network: Corporate Office     (Service: —)
  "From VPN"          →  Network: VPN                  (Service: —)
  "Stripe Requests"   →  Header Rule: Stripe Webhook   (Service: —)

Share Policy: "Engineering"
  Roles: engineering, senior-engineers
  Rules: From Office OR From VPN OR Stripe Requests

A user with the engineering role can create a tunnel to a loopback target only (no rule in this policy pins a Service). Once a tunnel is up, inbound requests are allowed if they originate from 203.0.113.0/24, from 10.8.0.0/16, or carry a Stripe-Signature header.

Pinning a tunnel to a registered Service

Services:
  "Staging API"        →  http://staging-api.internal:8080

Share Rules:
  "Staging API / VPN"  →  Network: VPN  +  Service: Staging API

Share Policy: "Backend"
  Roles: backend
  Rules: Staging API / VPN

A user with the backend role can create a tunnel pointed at staging-api.internal:8080 (the registered Service), but only inbound requests originating from the VPN’s CIDR will reach the tunnel. The same role has no other rule, so it cannot share any other non-loopback target — and a loopback target is also denied here, because the rule’s Service field is pinned (it’s not “any” — it’s “this Service”).

Note

Share tunnels carry HTTP and HTTPS only. A Service’s Backend Target must be an http:// or https:// URL — raw TCP services (databases, SSH, custom protocols) are out of scope for Share.

Trusted Proxy CIDRs

Network rules compare against the real client IP, extracted from X-Forwarded-For. For this to work correctly, you must configure the IP ranges of your reverse proxy in Configuration → Reverse Proxy — otherwise the proxy IP is used instead of the client IP, and network rules will not behave as expected.