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. Share Rules

A Share Rule composes a Network and/or a Header Rule into a single named condition.

• A Share Rule with no Network and no Header Rule matches all traffic (useful for role-only gating with no traffic restrictions).
• A Share Rule with only a Network matches requests from those CIDRs.
• A Share Rule with only a Header Rule matches requests with those headers.
• A Share Rule with both restricts to traffic matching the Network and the Header Rule.

4. 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.

Example

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
  "From VPN"          →  Network: VPN
  "Stripe Requests"   →  Header Rule: Stripe Webhook

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. Inbound requests to that tunnel are allowed if they originate from 203.0.113.0/24, from 10.8.0.0/16, or carry a Stripe-Signature header.

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 Settings — otherwise the proxy IP is used instead of the client IP, and network rules will not behave as expected.