Shares overview

Shares in NetFoundry Frontdoor enable you to expose your internal services to the public internet securely and efficiently. A share creates a publicly accessible endpoint that routes traffic to your backend services without requiring you to open firewall ports or modify your network security configuration.

A share is a public access point that makes your HTTP/HTTPS services available on the internet through NetFoundry Frontdoor's infrastructure. When you create a share, NetFoundry Frontdoor generates a public URL that users can access from anywhere on the internet while establishing a secure zero-trust tunnel between the Frontdoor infrastructure and your backend service. It routes incoming requests from the public URL to your specified backend endpoint and handles SSL/TLS termination and security at the edge automatically.

How shares work

The share acts as a bridge between the public internet and your private services by providing users with a public URL through NetFoundry Frontdoor while NetFoundry's infrastructure securely routes traffic to your backend. Your backend service remains protected behind your firewall without requiring any inbound ports to be opened, and SSL/TLS termination, DDoS protection, and other security features are handled automatically.

Security considerations

Automatic security features

All traffic is protected with SSL/TLS encryption while DDoS protection operates at the edge to defend against attacks. Request filtering and validation ensure only legitimate traffic reaches your backend services, complemented by rate limiting and throttling mechanisms that prevent abuse and maintain service stability.

Access control

While shares create public endpoints, you should implement appropriate authentication and authorization in your backend services. NetFoundry Frontdoor provides the secure transport layer, but application-level security remains your responsibility.

Temporary access

Shares can be created and destroyed as needed, making them ideal for temporary access scenarios. When you delete a share, the public endpoint is immediately removed.

Best practices

Naming convention

Use descriptive names for your shares that clearly identify the service and purpose:

api-production-v2
demo-customer-portal
staging-webhook-handler

Backend health

Ensure your backend services are healthy and responsive before creating shares. Monitor your backend performance as public traffic patterns may differ from internal usage. Health Checks can help you ensure your backend services are operating as expected.

Resource management

Clean up unused shares regularly to maintain a tidy environment while monitoring share metrics to understand usage patterns and performance trends. Plan for appropriate scaling measures if your share experiences high traffic volumes to ensure consistent service availability.

Security

Implement proper authentication mechanisms in your backend services and use HTTPS for backend communications whenever possible. Monitor access logs consistently for suspicious activity patterns and consider implementing rate limiting within your application to prevent abuse and maintain service quality.

HTTP shares

HTTP shares let you expose HTTP/HTTPS applications through a Frontdoor-managed endpoint without opening inbound firewall ports. The Frontdoor terminates TLS at the edge and securely proxies requests to your private target service. You can optionally require user authentication (for example, OAuth) before requests reach your backend.

Key concepts

Frontend binding: you select a Frontend (NetFoundry hosted or custom) for the share's public hostname. Requests to those Frontends are routed to your target.
Target: the internal URL your service listens on, e.g., http://backend.svc.cluster.local:8080 or https://app.internal.local.
TLS termination at the edge: client HTTPS connections terminate at Frontdoor. Backend connections to https:// targets are validated unless you explicitly mark them as insecure.
Optional authentication: attach an Auth Provider to enforce OAuth-based access control with optional email-domain filters.

Prerequisites

At least one Frontend available and, if using a custom domain, DNS pointing to the Frontend.
An online Agent connected to the target Environment to route traffic to your backend.
If using OAuth/authentication, create the Auth Provider first so you can reference its id.
- See: Frontends and Authentication

Request fields specific to HTTP

type: "http"
frontendIds (required): a Frontend id to bind this share to
target (required): your private service URL, e.g., http://backend.svc.cluster.local:8080
authProviderId (optional): id of an Auth Provider to require OAuth sign-in
oauthEmailDomains (optional): allowed email domains for authenticated users
oauthAuthorizationCheckInterval (optional): ISO-8601 duration for re-checking authorization, e.g., "PT15M"
insecure (optional): true to skip TLS certificate verification when proxying to an HTTPS target (use only for trusted, internal, self-signed backends)

Notes

insecure affects only backend verification to your https:// target. Client-to-Frontdoor traffic remains fully validated TLS.

Email domain filtering applies only when authProviderId is set.

Create a simple public share bound to a Frontend, targeting an internal HTTP service:

curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "type": "http",
        "name": "publicdemo",
        "envZId": "ijcrWb-ZOq",
        "frontendIds": [ "bMTHPrtQ" ],
        "target": "http://backend.svc.cluster.local:8080"
      }' \
  "https://gateway.production.netfoundry.io/frontdoor/$FRONTDOOR_ID/shares"

Require sign-in via an existing Auth Provider and allow only specific email domains. This example also shows how to allow an internal HTTPS target with a self-signed certificate:

curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "type": "http",
        "name": "portal",
        "envZId": "ijcrWb-ZOq",
        "frontendIds": [ "dKRfL_UMa8DAP7KmYOdOr" ],
        "target": "https://portal.internal.local",
        "authProviderId": "ap_123456",
        "oauthEmailDomains": [ "example.com", "subsidiary.example" ],
        "oauthAuthorizationCheckInterval": "PT15M",
        "insecure": true
      }' \
  "https://gateway.production.netfoundry.io/frontdoor/$FRONTDOOR_ID/shares"

TCP shares

TCP shares let you expose non-HTTP services (for example, SSH, databases, message brokers) over a secure TCP tunnel without opening inbound firewall ports. They are ideal when your application speaks a raw TCP protocol and you want to enforce mutual TLS (mTLS) with client certificates.

Key concepts

Public TCP ingress: traffic enters via a Frontdoor-managed TCP endpoint and is tunneled to your private target.
Ingress port range: you choose an external TCP port in the range 2100–2199 to listen on for this share.
Target: the private TCP endpoint your service listens on (host:port). You may specify a URI form like tcp://host:port or host:port.
Client authentication (optional): restrict access with client certificates and subject filters.

Prerequisites

TCP shares must be enabled on the Frontdoor. If disabled, all requests will be rejected. Contact support to enable it.
An online Agent connected to the target Environment to route traffic.
If using client certificate authentication, create or upload the certificate first so you can reference its id.
- See: Create a client certificate

Request fields specific to TCP

type: "tcp"
ingressPort (required): external port in 2100..2199 that clients connect to
target (required): your private service address, e.g., tcp://db.internal.local:5432
clientCertificateId (optional): the ID of a stored client certificate to require mTLS
allowedSubjects (optional): exact subject DNs permitted to connect
allowedCommonNamePrefixes (optional): allow-list by CN prefix
requiredOrganizationalUnit (optional): require a specific OU in the client cert subject

Notes

You may combine allowedSubjects, allowedCommonNamePrefixes, and requiredOrganizationalUnit. All specified constraints must pass for the client certificate to be accepted.

If clientCertificateId is omitted, the TCP share does not require a client certificate.

Example — Intermediate CA with assurances (OU and/or CN prefix)

Each frontdoor has a built-in intermediate CA that is used to sign client certificates. This example shows how to create a TCP share that requires a client certificate issued by the built-in intermediate CA and enforces assurances: 1

Create a TCP share that trusts that intermediate and enforces assurances:

curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "type": "tcp",
        "name": "svc-ssh",
        "envZId": "ijcrWb-ZOq",
        "ingressPort": 2142,
        "target": "tcp://ssh.internal.local:22",
        "requiredOrganizationalUnit": "engineering",
        "allowedCommonNamePrefixes": [ "svc-" ]
      }' \
  "https://gateway.production.netfoundry.io/frontdoor/$FRONTDOOR_ID/shares"

Only client certificates issued by the intermediate AND matching OU=engineering AND with CN starting with svc- will be accepted.

Connect using a leaf certificate issued by that intermediate:

openssl s_client -connect your-tcp-endpoint.example.com:2142 \
  -cert client.crt -key client.key -quiet

Tip

For best interoperability, include the full client chain in client.crt (leaf first, then any intermediates). The Frontdoor validates the presented chain up to the uploaded intermediate.

Example — Pinned Client Certificate

Accept exactly one client certificate by pinning to a single Client Certificate. This is useful for highly restricted access.

Create the TCP share and pin to the client certificate:

curl -s -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "type": "tcp",
        "name": "db-admin",
        "envZId": "ijcrWb-ZOq",
        "ingressPort": 2155,
        "target": "tcp://db.internal.local:5432",
        "clientCertificateId": "fdkjasd74h"
      }' \
  "https://gateway.production.netfoundry.io/frontdoor/$FRONTDOOR_ID/shares"

Only the certificate created in the Client Certificate Management section will be accepted.

Connect with the pinned certificate:

openssl s_client -connect your-tcp-endpoint.example.com:2155 \
  -cert client.crt -key client.key -quiet

Notes

Client Certificate pinning uses the exact certificate. If you re-issue the certificate it will stop working.

Operational tips

Use narrow allow-lists (allowedSubjects or CN prefixes) to scope access.
Rotate client certificates periodically and update clientCertificateId as needed.

More info

Learn how to create and manage shares using the API
Explore Frontends to understand how shares integrate with custom domains
Review Health Checks to ensure your backend services remain healthy

What is a share?​

How shares work​

Security considerations​

Automatic security features​

Access control​

Temporary access​

Best practices​

Naming convention​

Backend health​

Resource management​

Security​

HTTP shares​

Key concepts​

Prerequisites​

Request fields specific to HTTP​

Example A — Public HTTP share​

Example B — OAuth-protected HTTP share​

TCP shares​

Key concepts​

Prerequisites​

Request fields specific to TCP​

Example — Intermediate CA with assurances (OU and/or CN prefix)​

Example — Pinned Client Certificate​

Operational tips​

More info​

What is a share?

How shares work

Security considerations

Automatic security features

Access control

Temporary access

Best practices

Naming convention

Backend health

Resource management

Security

HTTP shares

Key concepts

Prerequisites

Request fields specific to HTTP

Example A — Public HTTP share

Example B — OAuth-protected HTTP share

TCP shares

Key concepts

Prerequisites

Request fields specific to TCP

Example — Intermediate CA with assurances (OU and/or CN prefix)

Example — Pinned Client Certificate

Operational tips

More info