diff --git a/docs/cli/commands/gateway.mdx b/docs/cli/commands/gateway.mdx index 99d0e10865..bddbf614c9 100644 --- a/docs/cli/commands/gateway.mdx +++ b/docs/cli/commands/gateway.mdx @@ -9,7 +9,7 @@ description: "Run the Infisical gateway or manage its systemd service" infisical gateway start --name= --relay= --auth-method= ``` - + ```bash sudo infisical gateway systemd install --token= --domain= --name= --relay= ``` @@ -25,29 +25,29 @@ The gateway system uses SSH reverse tunnels over TCP, eliminating firewall compl **Deprecation and Migration Notice:** The legacy `infisical gateway` command (v1) will be removed in a future release. Please migrate to `infisical gateway start` (Gateway v2). -If you are moving from Gateway v1 to Gateway v2, this is NOT a drop-in switch. Gateway v2 creates new gateway instances with new gateway IDs. You must update any existing resources that reference gateway IDs (for example: dynamic secret configs, app connections, or other gateway-bound resources) to point to the new Gateway v2 gateway ID. Until you update those references, traffic will continue to target the old v1 gateway. +If you are moving from Gateway v1 to Gateway v2, this is NOT a drop-in switch. Gateway v2 creates new gateway instances with new gateway IDs. You must update any existing resources that reference gateway IDs (for example: dynamic secret configs, app connections, or other gateway-bound resources) to point to the new Gateway v2 gateway resource. Until you update those references, traffic will continue to target the old v1 gateway. ## Subcommands & flags - Run the Infisical gateway component within your VPC. The gateway establishes an SSH reverse tunnel to the specified relay server and provides secure access to private resources. + Run the Infisical gateway component within your the network where your target resources are located. The gateway establishes an SSH reverse tunnel to the specified relay server and provides secure access to private resources within your network. ```bash infisical gateway start --relay= --name= --auth-method= ``` -The gateway component: +Once started, the gateway component will: -- Establishes outbound SSH reverse tunnels to relay servers (no inbound firewall rules needed) -- Authenticates using SSH certificates issued by Infisical -- Automatically reconnects if the connection is lost -- Provides access to private resources within your network +- Establish outbound SSH reverse tunnels to relay servers (no inbound firewall rules needed) +- Authenticate using SSH certificates issued by Infisical +- Automatically reconnect if the connection is lost +- Provide access to private resources within your network ### Authentication -The Infisical CLI supports multiple authentication methods. Below are the available authentication methods, with their respective flags. +The Relay supports multiple authentication methods. Below are the available authentication methods, with their respective flags. @@ -361,12 +361,12 @@ sudo systemctl disable infisical-gateway # Disable auto-start on boot -## Legacy Gateway Commands (Deprecated) +## Legacy Gateway Commands **This command is deprecated and will be removed in a future release.** - + Please migrate to `infisical gateway start` for the new TCP-based SSH tunnel architecture. **Migration required:** If you are currently using Gateway v1 (via `infisical gateway`), moving to Gateway v2 is not in-place. Gateway v2 provisions new gateway instances with new gateway IDs. Update any resources that reference a gateway ID (for example: dynamic secret configs, app connections, or other gateway-bound resources) to use the new Gateway v2 gateway ID. Until you update those references, traffic will continue to target the old v1 gateway. @@ -593,7 +593,7 @@ The Infisical CLI supports multiple authentication methods. Below are the availa **This command is deprecated and will be removed in a future release.** - + Please migrate to `infisical gateway systemd install` for the new TCP-based SSH tunnel architecture with enhanced security and better performance. **Migration required:** If you previously installed Gateway v1 via `infisical gateway install`, moving to Gateway v2 is not in-place. Gateway v2 provisions new gateway instances with new gateway IDs. Update any resources that reference a gateway ID (for example: dynamic secret configs, app connections, or other gateway-bound resources) to use the new Gateway v2 gateway ID. Until you update those references, traffic will continue to target the old v1 gateway. diff --git a/docs/cli/commands/relay.mdx b/docs/cli/commands/relay.mdx index 46a061da30..b377b9ce21 100644 --- a/docs/cli/commands/relay.mdx +++ b/docs/cli/commands/relay.mdx @@ -6,88 +6,70 @@ description: "Relay-related commands for Infisical" ```bash - infisical relay start --type= --host= --name= --auth-method= + infisical relay start --host= --name= --auth-method= + ``` + + + ```bash + # Install systemd service + sudo infisical relay systemd install --host= --name= --token= + + # Uninstall systemd service + sudo infisical relay systemd uninstall ``` ## Description -Relay-related commands for Infisical that provide identity-aware relay infrastructure for routing encrypted traffic: - -- **Relay**: Identity-aware server that routes encrypted traffic (can be instance-wide or organization-specific) - -The relay system uses SSH reverse tunnels over TCP, eliminating firewall complexity and providing excellent performance for enterprise environments. +Relay-related commands for Infisical that provide identity-aware relay infrastructure for routing encrypted traffic. Relays are organization-deployed servers that route encrypted traffic between Infisical and your gateways. ## Subcommands & flags - Run the Infisical relay component. The relay handles network traffic routing and can operate in different modes. + Run the Infisical relay component. The relay handles network traffic routing between Infisical and your gateways. ```bash -infisical relay start --type= --host= --name= --auth-method= +infisical relay start --host= --name= --auth-method= ``` ### Flags - - The type of relay to run. Must be either 'instance' or 'org'. - - - **`instance`**: Shared relay server that can be used by all organizations on your Infisical instance. Set up by the instance administrator. Uses `INFISICAL_RELAY_AUTH_SECRET` environment variable for authentication, which must be configured by the instance admin. - - **`org`**: Dedicated relay server that individual organizations deploy and manage in their own infrastructure. Provides enhanced security, custom geographic placement, and compliance benefits. Uses standard Infisical authentication methods. - - ```bash - # Organization relay (customer-deployed) - infisical relay start --type=org --host=192.168.1.100 --name=my-org-relay - - # Instance relay (configured by instance admin) - INFISICAL_RELAY_AUTH_SECRET= infisical relay start --type=instance --host=10.0.1.50 --name=shared-relay - ``` - - - The host (IP address or hostname) of the instance where the relay is deployed. This must be a static public IP or resolvable hostname that gateways can reach. ```bash # Example with IP address - infisical relay start --host=203.0.113.100 --type=org --name=my-relay + infisical relay start --host=203.0.113.100 --name=my-relay # Example with hostname - infisical relay start --host=relay.example.com --type=org --name=my-relay + infisical relay start --host=relay.example.com --name=my-relay ``` - The name of the relay. + The name of the relay. This is an arbitrary identifier for your relay instance. ```bash # Example - infisical relay start --name=my-relay --type=org --host=192.168.1.100 + infisical relay start --name=my-relay --host=192.168.1.100 ``` ### Authentication -**Organization Relays (`--type=org`):** -Deploy your own relay server in your infrastructure for enhanced security and reduced latency. Supports all standard Infisical authentication methods documented below. - -**Instance Relays (`--type=instance`):** -Shared relay servers that serve all organizations on your Infisical instance. For Infisical Cloud, these are already running and ready to use. For self-hosted deployments, they're set up by the instance administrator. Authentication is handled via the `INFISICAL_RELAY_AUTH_SECRET` environment variable. +Relays support all standard Infisical authentication methods. Choose the authentication method that best fits your environment and set the corresponding flags when starting the relay. ```bash -# Organization relay with Universal Auth (customer-deployed) -infisical relay start --type=org --host=192.168.1.100 --name=my-org-relay --auth-method=universal-auth --client-id= --client-secret= - -# Instance relay (configured by instance admin) -INFISICAL_RELAY_AUTH_SECRET= infisical relay start --type=instance --host=10.0.1.50 --name=shared-relay +# Example with Universal Auth +infisical relay start --host=192.168.1.100 --name=my-relay --auth-method=universal-auth --client-id= --client-secret= ``` -### Authentication Methods +### Available Authentication Methods -The Infisical CLI supports multiple authentication methods for organization relays. Below are the available authentication methods, with their respective flags. +The Infisical CLI supports multiple authentication methods for relays. Below are the available authentication methods, with their respective flags. @@ -108,7 +90,7 @@ The Infisical CLI supports multiple authentication methods for organization rela ```bash - infisical relay start --auth-method=universal-auth --client-id= --client-secret= --type=org --host= --name= + infisical relay start --auth-method=universal-auth --client-id= --client-secret= --host= --name= ``` @@ -132,7 +114,7 @@ The Infisical CLI supports multiple authentication methods for organization rela ```bash - infisical relay start --auth-method=kubernetes --machine-identity-id= --type=org --host= --name= + infisical relay start --auth-method=kubernetes --machine-identity-id= --host= --name= ``` @@ -153,7 +135,7 @@ The Infisical CLI supports multiple authentication methods for organization rela ```bash - infisical relay start --auth-method=azure --machine-identity-id= --type=org --host= --name= + infisical relay start --auth-method=azure --machine-identity-id= --host= --name= ``` @@ -174,7 +156,7 @@ The Infisical CLI supports multiple authentication methods for organization rela ```bash - infisical relay start --auth-method=gcp-id-token --machine-identity-id= --type=org --host= --name= + infisical relay start --auth-method=gcp-id-token --machine-identity-id= --host= --name= ``` @@ -196,7 +178,7 @@ The Infisical CLI supports multiple authentication methods for organization rela ```bash - infisical relay start --auth-method=gcp-iam --machine-identity-id= --service-account-key-file-path= --type=org --host= --name= + infisical relay start --auth-method=gcp-iam --machine-identity-id= --service-account-key-file-path= --host= --name= ``` @@ -215,7 +197,7 @@ The Infisical CLI supports multiple authentication methods for organization rela ```bash - infisical relay start --auth-method=aws-iam --machine-identity-id= --type=org --host= --name= + infisical relay start --auth-method=aws-iam --machine-identity-id= --host= --name= ``` @@ -237,7 +219,7 @@ The Infisical CLI supports multiple authentication methods for organization rela ```bash - infisical relay start --auth-method=oidc-auth --machine-identity-id= --jwt= --type=org --host= --name= + infisical relay start --auth-method=oidc-auth --machine-identity-id= --jwt= --host= --name= ``` @@ -261,7 +243,7 @@ The Infisical CLI supports multiple authentication methods for organization rela ```bash - infisical relay start --auth-method=jwt-auth --jwt= --machine-identity-id= --type=org --host= --name= + infisical relay start --auth-method=jwt-auth --jwt= --machine-identity-id= --host= --name= ``` @@ -277,30 +259,132 @@ The Infisical CLI supports multiple authentication methods for organization rela ```bash - infisical relay start --token= --type=org --host= --name= + infisical relay start --token= --host= --name= ``` -### Deployment Considerations + + + + Manage systemd service for Infisical relay. This allows you to install and run the relay as a systemd service on Linux systems. + ### Requirements + - **Operating System**: Linux only (systemd is not supported on other operating systems) + - **Privileges**: Root/sudo privileges required for both install and uninstall operations + - **Systemd**: The system must be running systemd as the init system + +```bash +infisical relay systemd +``` + +### Subcommands + + + Install and enable systemd service for the relay. Must be run with sudo on Linux systems. + +```bash +sudo infisical relay systemd install --host= --name= --token= [flags] +``` + +#### Flags + + + The host (IP address or hostname) of the instance where the relay is deployed. This must be a static public IP or resolvable hostname that gateways can reach. + +```bash +# Example with IP address +sudo infisical relay systemd install --host=203.0.113.100 --name=my-relay --token= + +# Example with hostname +sudo infisical relay systemd install --host=relay.example.com --name=my-relay --token= +``` + + + + + The name of the relay. + +```bash +# Example +sudo infisical relay systemd install --name=my-relay --host=192.168.1.100 --token= +``` + + + + + Connect with Infisical using machine identity access token. + +```bash +# Example +sudo infisical relay systemd install --token= --host= --name= +``` + + + + + Domain of your self-hosted Infisical instance. Optional flag for specifying a custom domain. + +```bash +# Example +sudo infisical relay systemd install --domain=http://localhost:8080 --token= --host= --name= +``` + + + +#### Examples + +```bash +# Install relay with token authentication +sudo infisical relay systemd install --host=192.168.1.100 --name=my-relay --token= + +# Install with custom domain +sudo infisical relay systemd install --domain=http://localhost:8080 --token= --host= --name= +``` + +#### Post-installation + +After successful installation, the service will be enabled but not started. To start the service: + +```bash +sudo systemctl start infisical-relay +``` + +To check the service status: + +```bash +sudo systemctl status infisical-relay +``` + +To view service logs: + +```bash +sudo journalctl -u infisical-relay -f +``` -**When to use Instance Relays (`--type=instance`):** + + + + Uninstall and remove systemd service for the relay. Must be run with sudo on Linux systems. + +```bash +sudo infisical relay systemd uninstall +``` -- You want to get started quickly without setting up your own relay infrastructure -- You're using Infisical Cloud and want to leverage the existing relay infrastructure -- You're on a self-hosted instance where the admin has already set up shared relays -- You don't need custom geographic placement of relay servers -- You don't have specific compliance requirements that require dedicated infrastructure -- You want to minimize operational overhead by using shared infrastructure +#### Examples -**When to use Organization Relays (`--type=org`):** +```bash +# Uninstall the relay systemd service +sudo infisical relay systemd uninstall +``` + +#### What it does -- You need lower latency by deploying relay servers closer to your resources -- You have security requirements that mandate running infrastructure in your own environment -- You have compliance requirements such as data sovereignty or air-gapped environments -- You need custom network policies or specific networking configurations -- You have high-scale performance requirements that shared infrastructure can't meet -- You want full control over your relay infrastructure and its configuration +- Stops the `infisical-relay` systemd service if it's running +- Disables the service from starting on boot +- Removes the systemd service file +- Cleans up the service configuration + + diff --git a/docs/docs.json b/docs/docs.json index 285e11a608..9eeeea500a 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -173,8 +173,9 @@ "group": "Gateway", "pages": [ "documentation/platform/gateways/overview", - "documentation/platform/gateways/gateway-security", - "documentation/platform/gateways/networking", + "documentation/platform/gateways/gateway-deployment", + "documentation/platform/gateways/relay-deployment", + "documentation/platform/gateways/security", { "group": "Gateway (Deprecated)", "pages": [ diff --git a/docs/documentation/platform/gateways/gateway-deployment.mdx b/docs/documentation/platform/gateways/gateway-deployment.mdx new file mode 100644 index 0000000000..40b98965a4 --- /dev/null +++ b/docs/documentation/platform/gateways/gateway-deployment.mdx @@ -0,0 +1,265 @@ +--- +title: "Gateway Deployment" +description: "Complete guide to deploying Infisical Gateways including network configuration and firewall requirements" +--- + +Infisical Gateways enables secure communication between your private resources and the Infisical platform without exposing inbound ports in your network. +This guide covers everything you need to deploy and configure Infisical Gateways. + +## Deployment Steps + +To successfully deploy an Infisical Gateway for use, follow these steps in order. + + + + Create a machine identity with the correct permissions to create and manage gateways. This identity is used by the gateway to authenticate with Infisical and should be provisioned in advance. + The gateway supports several [machine identity auth methods](/documentation/platform/identities/machine-identities), as listed below. Choose the one that best fits your environment and set the corresponding environment variables when deploying the gateway. + + + + Simple and secure authentication using client ID and client secret. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=universal-auth` + - `INFISICAL_UNIVERSAL_AUTH_CLIENT_ID=` + - `INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET=` + + + + Direct authentication using a machine identity access token. + + **Environment Variables:** + - `INFISICAL_TOKEN=` + + + + Authentication using Kubernetes service account tokens. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=kubernetes` + - `INFISICAL_MACHINE_IDENTITY_ID=` + + + + Authentication using AWS IAM roles. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=aws-iam` + - `INFISICAL_MACHINE_IDENTITY_ID=` + + + + Authentication using GCP identity tokens. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=gcp-id-token` + - `INFISICAL_MACHINE_IDENTITY_ID=` + + + + Authentication using GCP service account keys. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=gcp-iam` + - `INFISICAL_MACHINE_IDENTITY_ID=` + - `INFISICAL_GCP_SERVICE_ACCOUNT_KEY_FILE_PATH=` + + + + Authentication using Azure managed identity. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=azure` + - `INFISICAL_MACHINE_IDENTITY_ID=` + + + + Authentication using OIDC identity tokens. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=oidc-auth` + - `INFISICAL_MACHINE_IDENTITY_ID=` + - `INFISICAL_JWT=` + + + + Authentication using JWT tokens. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=jwt-auth` + - `INFISICAL_MACHINE_IDENTITY_ID=` + - `INFISICAL_JWT=` + + + + + Ensure a relay server is running and accessible before you deploy any gateways. You have two options: + - **Managed relay (Infisical Cloud, US/EU only):** Managed relays are only available for Infisical Cloud instances in the US and EU regions. If you are using Infisical Cloud in these regions, you can use the provided managed relay. + - **Self-hosted relay:** For all other cases, including all self-hosted and dedicated enterprise instances of Infisical, you must deploy your own relay server. You can also choose to deploy your own relay server when using Infisical Cloud if you require reduced geographic proximity to your target resources for lower latency or to reduce network congestion. For setup instructions, see the Relay Deployment Guide. + + + Make sure the Infisical CLI is installed on the machine or environment where you plan to deploy the gateway. The CLI is required for gateway installation and management. + + See the [CLI Installation Guide](/cli/overview) for instructions. + + + Ensure your network and firewall settings allow the gateway to connect to all required services. All connections are outbound only; no inbound ports need to be opened. + + | Protocol | Destination | Port | Purpose | + | -------- | ------------------------------------ | ---- | ------------------------------------------ | + | TCP | Relay Server IP/Hostname | 2222 | SSH reverse tunnel establishment | + | TCP | Infisical instance host (US/EU, other) | 443 | API communication and certificate requests | + + For managed relays, allow outbound traffic to the provided relay server IP/hostname. For self-hosted relays, allow outbound traffic to your own relay server address. + + If you are in a corporate environment with strict egress filtering, ensure outbound TCP 2222 to relay servers and outbound HTTPS 443 to Infisical API endpoints are allowed. + + + The Infisical CLI is used to install and start the gateway in your chosen environment. The CLI provides commands for both production and development scenarios, and supports a variety of options/flags to configure your deployment. + + To view all available flags and equivalent environment variables for gateway deployment, see the [Gateway CLI Command Reference](/cli/commands/gateway). + + + For production deployments on Linux servers, install the Gateway as a systemd service so that it runs securely in the background and automatically restarts on failure or system reboot: + ```bash + sudo infisical gateway systemd install --token --domain --name --relay + sudo systemctl start infisical-gateway + ``` + + + + + The systemd install command requires a Linux operating system with root/sudo + privileges. + + + + + For production deployments on Kubernetes clusters, install the Gateway using the Infisical Helm chart: + + #### Install the latest Helm Chart repository + + ```bash + helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/' + helm repo update + ``` + + #### Create a Kubernetes Secret + + The gateway supports all identity authentication methods through environment variables: + + ```bash + kubectl create secret generic infisical-gateway-environment \ + --from-literal=INFISICAL_AUTH_METHOD=universal-auth \ + --from-literal=INFISICAL_UNIVERSAL_AUTH_CLIENT_ID= \ + --from-literal=INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET= \ + --from-literal=INFISICAL_RELAY_NAME= \ + --from-literal=INFISICAL_GATEWAY_NAME= + ``` + + #### Install the Gateway + + ```bash + helm install infisical-gateway infisical-helm-charts/infisical-gateway + ``` + + + + For development or testing environments: + + ```bash + infisical gateway start --token --relay= --name= + ``` + + + + + + After deployment, verify your gateway is working: + + 1. **Check logs** for "Gateway started successfully" message indicating the gateway is running and connected to the relay + + 2. **Verify registration** in the Infisical by visiting the Gateways section of your organization. The new gateway should appear with a recent heartbeat timestamp. + + 3. **Test connectivity** by creating a resource in Infisical that uses the gateway to access a private service. Verify the resource can successfully connect through the gateway. + + + + + + +## Frequently Asked Questions + +No inbound ports need to be opened for gateways. The gateway only makes outbound connections: + +- **Outbound SSH** to relay servers on port 2222 +- **Outbound HTTPS** to Infisical API endpoints on port 443 +- **SSH reverse tunnels** handle all communication - no return traffic configuration needed + +This design maintains security by avoiding the need for inbound firewall rules that could expose your network to external threats. + + + + +Test relay connectivity and outbound API access from the gateway: + +1. Test SSH port to relay: + ```bash + nc -zv 2222 + ``` +2. Test outbound API access (replace with your Infisical domain if different): + ```bash + curl -I https://app.infisical.com + ``` + + + +If the gateway cannot connect to the relay: + +1. Verify the relay server is running and accessible +2. Check firewall rules allow outbound connections on port 2222 +3. Confirm the relay name matches exactly +4. Test SSH port to relay: + ```bash + nc -zv 2222 + ``` + + + +If you encounter authentication failures: + +1. Verify machine identity credentials are correct +2. Check token expiration and renewal +3. Ensure authentication method is properly configured + + + +Check gateway logs for detailed error information: + +- **systemd service:** + ```bash + sudo journalctl -u infisical-gateway -f + ``` +- **Kubernetes:** + ```bash + kubectl logs deployment/infisical-gateway + ``` +- **Local installation:** Logs appear in the terminal where you started the gateway + + + +For systemd-based installations, the gateway's configuration file is stored at `/etc/infisical/gateway.conf`. You may reference or inspect this file for troubleshooting advanced configuration issues. + + + +The gateway is designed to handle network interruptions gracefully: + +- **Automatic reconnection**: The gateway will automatically attempt to reconnect to relay servers if the SSH connection is lost +- **Connection retry logic**: Built-in retry mechanisms handle temporary network outages without manual intervention +- **Persistent SSH tunnels**: SSH connections are automatically re-established when connectivity is restored +- **Certificate rotation**: The gateway handles certificate renewal automatically during reconnection +- **Graceful degradation**: The gateway logs connection issues and continues attempting to restore connectivity + +No manual intervention is typically required during network interruptions. + + diff --git a/docs/documentation/platform/gateways/networking.mdx b/docs/documentation/platform/gateways/networking.mdx deleted file mode 100644 index 2b068a5350..0000000000 --- a/docs/documentation/platform/gateways/networking.mdx +++ /dev/null @@ -1,178 +0,0 @@ ---- -title: "Networking" -description: "Network configuration and firewall requirements for Infisical Gateway" ---- - -The Infisical Gateway requires outbound network connectivity to establish secure SSH reverse tunnels with relay servers. -This page outlines the required ports, protocols, and firewall configurations needed for optimal gateway usage. - -## Network Architecture - -The gateway uses SSH reverse tunnels to establish secure connections with end-to-end encryption: - -1. **Gateway** connects outbound to **Relay Servers** using SSH over TCP -2. **Infisical platform** establishes mTLS connections with gateways for application traffic -3. **Relay Servers** route the doubly-encrypted traffic (mTLS payload within SSH tunnels) between the platform and gateways -4. **Double encryption** ensures relay servers cannot access application data - only the platform and gateway can decrypt traffic - -## Required Network Connectivity - -### Outbound Connections (Required) - -The gateway requires the following outbound connectivity: - -| Protocol | Destination | Ports | Purpose | -| -------- | ------------------------------------ | ----- | ------------------------------------------ | -| TCP | Relay Servers | 2222 | SSH reverse tunnel establishment | -| TCP | app.infisical.com / eu.infisical.com | 443 | API communication and certificate requests | - -### Relay Server Connectivity - -**For Instance Relays (Infisical Cloud):** Your firewall must allow outbound connectivity to Infisical-managed relay servers. - -**For Organization Relays:** Your firewall must allow outbound connectivity to your own relay server IP addresses or hostnames. - -**For Self-hosted Instance Relays:** Your firewall must allow outbound connectivity to relay servers configured by your instance administrator. - - - - Infisical provides multiple managed relay servers with static IP addresses. - You can whitelist these IPs ahead of time based on which relay server you - choose to connect to. **Firewall requirements:** Allow outbound TCP - connections to the desired relay server IP on port 2222. - - - You control the relay server IP addresses or hostnames when deploying your - own organization relays. **Firewall requirements:** Allow outbound TCP - connections to your relay server IP or hostname on port 2222. For example, - if your relay is at `203.0.113.100` or `relay.example.com`, allow TCP to - `203.0.113.100:2222` or `relay.example.com:2222`. - - - Contact your instance administrator for the relay server IP addresses or - hostnames configured for your deployment. **Firewall requirements:** Allow - outbound TCP connections to instance relay servers on port 2222. - - - -## Protocol Details - -### SSH over TCP - -The gateway uses SSH reverse tunnels for primary communication: - -- **Port 2222**: SSH connection to relay servers -- **Built-in features**: Automatic reconnection, certificate-based authentication, encrypted tunneling -- **Encryption**: SSH with certificate-based authentication and key exchange - -## Firewall Configuration for SSH - -The gateway uses standard SSH over TCP, making firewall configuration straightforward. - -### TCP Connection Handling - -SSH connections over TCP are stateful and handled seamlessly by all modern firewalls: - -- **Established connections** are automatically tracked -- **Return traffic** is allowed for established outbound connections -- **No special configuration** needed for connection tracking -- **Standard SSH protocol** that enterprise firewalls handle well - -### Simplified Firewall Rules - -Since SSH uses TCP, you only need simple outbound rules: - -1. **Allow outbound TCP** to relay servers (IP addresses or hostnames) on port 2222 -2. **Allow outbound HTTPS** to Infisical API endpoints on port 443 -3. **No inbound rules required** - all connections are outbound only - -## Common Network Scenarios - -### Corporate Firewalls - -For corporate environments with strict egress filtering: - -1. **Allow outbound TCP** to relay servers (IP addresses or hostnames) on port 2222 -2. **Allow outbound HTTPS** to the Infisical API server on port 443 -3. **No inbound rules required** - all connections are outbound only -4. **Standard TCP rules** - simple and straightforward configuration - -### Cloud Environments (AWS/GCP/Azure) - -Configure security groups to allow: - -- **Outbound TCP** to relay servers (IP addresses or hostnames) on port 2222 -- **Outbound HTTPS** to app.infisical.com/eu.infisical.com on port 443 -- **No inbound rules required** - SSH reverse tunnels are outbound only - -## Frequently Asked Questions - - -The gateway is designed to handle network interruptions gracefully: - -- **Automatic reconnection**: The gateway will automatically attempt to reconnect to relay servers if the SSH connection is lost -- **Connection retry logic**: Built-in retry mechanisms handle temporary network outages without manual intervention -- **Persistent SSH tunnels**: SSH connections are automatically re-established when connectivity is restored -- **Certificate rotation**: The gateway handles certificate renewal automatically during reconnection -- **Graceful degradation**: The gateway logs connection issues and continues attempting to restore connectivity - -No manual intervention is typically required during network interruptions. - - - - -SSH over TCP provides several advantages for enterprise gateway communication: - -- **Firewall-friendly**: TCP is stateful and handled seamlessly by all enterprise firewalls -- **Standard protocol**: SSH is a well-established protocol that network teams are familiar with -- **Certificate-based security**: Uses SSH certificates for strong authentication without shared secrets -- **Automatic tunneling**: SSH reverse tunnels handle all the complexity of secure communication -- **Enterprise compatibility**: Works reliably across all enterprise network configurations - -TCP's reliability and firewall compatibility make it ideal for enterprise environments where network policies are strictly managed. - - - - -No inbound ports need to be opened. The gateway only makes outbound connections: - -- **Outbound SSH** to relay servers on port 2222 -- **Outbound HTTPS** to Infisical API endpoints on port 443 -- **SSH reverse tunnels** handle all communication - no return traffic configuration needed - -This design maintains security by avoiding the need for inbound firewall rules that could expose your network to external threats. - - - - -If your firewall has strict outbound restrictions: - -1. **Work with your network team** to allow outbound TCP connections on port 2222 to relay servers (IP addresses or hostnames) -2. **Allow standard SSH traffic** - most enterprises already have SSH policies in place -3. **Consider network policy exceptions** for the gateway host if needed -4. **Monitor firewall logs** to identify which specific rules are blocking traffic - - - - -The gateway connects to **one relay server**: - -- **Single SSH connection**: Each gateway establishes one SSH reverse tunnel to its assigned relay server -- **Named relay assignment**: Gateways connect to the specific relay server specified by `--relay` -- **Automatic reconnection**: If the relay connection is lost, the gateway automatically reconnects to the same relay -- **Certificate-based authentication**: Each connection uses SSH certificates issued by Infisical for secure authentication - - - -No, relay servers cannot decrypt any traffic passing through them due to end-to-end encryption: - -- **Client-to-Gateway mTLS (via TLS-pinned tunnel)**: Clients connect via a proxy that establishes a TLS-pinned tunnel to the gateway; mTLS between the client and gateway is negotiated inside this tunnel, encrypting all application traffic -- **SSH tunnel encryption**: The mTLS-encrypted traffic is then transmitted through SSH reverse tunnels to relay servers -- **Double encryption**: Traffic is encrypted twice - once by client mTLS and again by SSH tunnels -- **Relay only routes traffic**: The relay server only routes the doubly-encrypted traffic without access to either encryption layer -- **No data storage**: Relay servers do not store any traffic or sensitive information -- **Certificate isolation**: Each connection uses unique certificates, ensuring complete tenant isolation - -The relay infrastructure is designed as a secure routing mechanism where only the client and gateway can decrypt the actual application traffic. - - diff --git a/docs/documentation/platform/gateways/overview.mdx b/docs/documentation/platform/gateways/overview.mdx index b8ea0102af..c04f2f7d3d 100644 --- a/docs/documentation/platform/gateways/overview.mdx +++ b/docs/documentation/platform/gateways/overview.mdx @@ -1,19 +1,14 @@ --- -title: "Gateway" +title: "Gateway Overview" sidebarTitle: "Overview" description: "How to access private network resources from Infisical" --- ![Architecture Overview](../../../images/platform/gateways/gateway-highlevel-diagram.png) -The Infisical Gateway provides secure access to private resources within your network without needing direct inbound connections to your environment. This method keeps your resources fully protected from external access while enabling Infisical to securely interact with resources like databases. - -**Architecture Components:** - -- **Gateway**: Lightweight agent deployed within your VPCs that provides access to private resources -- **Relay**: Infrastructure that routes encrypted traffic (instance-wide or organization-specific) - -Common use cases include generating dynamic credentials or rotating credentials for private databases. +The Infisical Gateway provides secure access to private resources within your network without needing direct inbound connections to your environment. +This is particularly useful when Infisical isn't hosted within the same network as the resources it needs to reach. +This method keeps your resources fully protected from external access while enabling Infisical to securely interact with resources like databases. Gateway is a paid feature available under the Enterprise Tier for Infisical @@ -22,428 +17,62 @@ Common use cases include generating dynamic credentials or rotating credentials license. -## How It Works - -The Gateway system uses SSH reverse tunnels for secure, firewall-friendly connectivity: - -1. **Gateway Registration**: The gateway establishes an outbound SSH reverse tunnel to a relay server using SSH certificates issued by Infisical -2. **Relay Routing**: The relay server routes encrypted traffic between the Infisical platform and gateways -3. **Resource Access**: The Infisical platform connects to your private resources through the established gateway connections - -**Key Benefits:** - -- **No inbound firewall rules needed** - all connections are outbound from your network -- **Firewall-friendly** - uses standard SSH over TCP -- **Certificate-based authentication** provides enhanced security -- **Automatic reconnection** if connections are lost - -## Deployment - -The Infisical Gateway is integrated into the Infisical CLI under the `gateway` command, making it simple to deploy and manage. -You can install the Gateway in all the same ways you install the Infisical CLI—whether via npm, Docker, or a binary. -For detailed installation instructions, refer to the Infisical [CLI Installation instructions](/cli/overview). - -**Prerequisites:** - -1. **Relay Server**: Before deploying gateways, you need a running relay server: - - **Infisical Cloud**: Instance relays are already available - no setup needed - - **Self-hosted**: Instance admin must set up shared instance relays, or organizations can deploy their own -2. **Machine Identity**: Configure a machine identity with appropriate permissions to create and manage gateways - -Once authenticated, the Gateway establishes an SSH reverse tunnel to the specified relay server, allowing secure access to your private resources. - -### Get started - - - - 1. Navigate to **Organization Access Control** in your Infisical dashboard. - 2. Create a dedicated machine identity for your Gateway. - 3. **Best Practice:** Assign a unique identity to each Gateway for better security and management. - ![Create Gateway Identity](../../../images/platform/gateways/create-identity-for-gateway.png) - - - - You'll need to choose an authentication method to initiate communication with Infisical. View the available machine identity authentication methods [here](/documentation/platform/identities/machine-identities). - - - - You have two options for relay infrastructure: - - - - **Infisical Cloud:** Instance relays are already running and available - **no setup required**. You can immediately proceed to deploy gateways using these shared relays. - - **Self-hosted:** If your instance admin has set up shared instance relays, you can use them directly. If not, the instance admin can set them up: - ```bash - # Instance admin sets up shared relay (one-time setup) - export INFISICAL_RELAY_AUTH_SECRET= - infisical relay start --type=instance --ip= --name= - ``` - - - **Available for all users:** Deploy your own dedicated relay infrastructure for enhanced control: - ```bash - # Deploy organization-specific relay - infisical relay start --type=org --ip= --name= --auth-method=universal-auth --client-id= --client-secret= - ``` - - **When to choose this:** - - You need lower latency (deploy closer to your resources) - - Enhanced security requirements - - Compliance needs (data sovereignty, air-gapped environments) - - Custom network policies - - - - - - Use the Infisical CLI to deploy the Gateway. You can run it directly or install it as a systemd service for production: - - - - For production deployments on Linux, install the Gateway as a systemd service: - - - **Gateway v2:** The `infisical gateway systemd install` command deploys the new Gateway v2 component. - - If you are migrating from Gateway v1 (legacy `infisical gateway install` command), this is not in-place. Gateway v2 provisions new gateway instances with new gateway IDs. Update any resources that reference a gateway ID (for example: dynamic secret configs, app connections, or other gateway-bound resources) to use the new Gateway v2 gateway ID. - - - ```bash - sudo infisical gateway systemd install --token --domain --name --relay - sudo systemctl start infisical-gateway - ``` - This will install and start the Gateway as a secure systemd service that: - - Runs with restricted privileges: - - Runs as root user (required for secure token management) - - Restricted access to home directories - - Private temporary directory - - Automatically restarts on failure - - Starts on system boot - - Manages token and domain configuration securely in `/etc/infisical/gateway.conf` - - - The install command requires: - - Linux operating system - - Root/sudo privileges - - Systemd - - - - - - The Gateway can be installed via [Helm](https://helm.sh/). Helm is a package manager for Kubernetes that allows you to define, install, and upgrade Kubernetes applications. - - For production deployments on Kubernetes, install the Gateway using the Infisical Helm chart: - - ### Install the latest Helm Chart repository - ```bash - helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/' - ``` - - ### Update the Helm Chart repository - ```bash - helm repo update - ``` - - ### Create a Kubernetes Secret containing gateway environment variables - - The gateway supports all identity authentication methods through the use of environment variables. - The environment variables must be set in the `infisical-gateway-environment` Kubernetes secret. - - - #### Supported authentication methods - - - - The Universal Auth method is a simple and secure way to authenticate with Infisical. It requires a client ID and a client secret to authenticate with Infisical. - - - - - Your machine identity client ID. - - - Your machine identity client secret. - - - The authentication method to use. Must be `universal-auth` when using Universal Auth. - - - - - ```bash - kubectl create secret generic infisical-gateway-environment \ - --from-literal=INFISICAL_AUTH_METHOD=universal-auth \ - --from-literal=INFISICAL_UNIVERSAL_AUTH_CLIENT_ID= \ - --from-literal=INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET= \ - --from-literal=INFISICAL_RELAY_NAME= \ - --from-literal=INFISICAL_GATEWAY_NAME= - ``` - - - - The Native Kubernetes method is used to authenticate with Infisical when running in a Kubernetes environment. It requires a service account token to authenticate with Infisical. +## Core Components - - - - Your machine identity ID. - - - Path to the Kubernetes service account token to use. Default: `/var/run/secrets/kubernetes.io/serviceaccount/token`. - - - The authentication method to use. Must be `kubernetes` when using Native Kubernetes. - - - +The Gateway system consists of two primary components working together to enable secure network access: + + + A Gateway is a lightweight service that you deploy within your own network infrastructure to provide secure access to your private resources. Think of it as a secure bridge between Infisical and your internal systems. - ```bash - kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=kubernetes --from-literal=INFISICAL_MACHINE_IDENTITY_ID= - ``` + Gateways must be deployed within the same network where your target resources are located, with direct network connectivity to the private resources you want Infisical to access. + For different networks, regions, or isolated environments, you'll need to deploy separate gateways. - - - The Native Azure method is used to authenticate with Infisical when running in an Azure environment. + **Core Functions:** + - **Network Placement**: Deployed within your VPCs, data centers, or on-premises infrastructure where your private resources live + - **Connection Model**: Only makes outbound connections to Infisical's relay servers, so no inbound firewall rules are needed + - **Security Method**: Uses SSH reverse tunnels with certificate-based authentication for maximum security + - **Resource Access**: Acts as a proxy to connect Infisical to your private databases, APIs, and other services + - - - - Your machine identity ID. - - - The authentication method to use. Must be `azure` when using Native Azure. - - - + + A Relay Server is the routing infrastructure that enables secure communication between the Infisical platform and your deployed gateways. It acts as an intermediary that never sees your actual data. - ```bash - kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=azure --from-literal=INFISICAL_MACHINE_IDENTITY_ID= - ``` - - - The Native GCP ID Token method is used to authenticate with Infisical when running in a GCP environment. + **Core Functions:** + - **Traffic Routing**: Routes encrypted traffic between the Infisical platform and your gateways without storing or inspecting the data + - **Network Isolation**: Enables secure communication without requiring direct network connections between Infisical and your private infrastructure + - **Authentication Management**: Validates SSH certificates and manages secure routing between authenticated gateways - - - - Your machine identity ID. - - - The authentication method to use. Must be `gcp-id-token` when using Native GCP ID Token. - - - + **Deployment Options:** + To reduce operational overhead, Infisical Cloud (US/EU) provides managed relay infrastructure, though organizations can also deploy their own relays for reduced latency. + - **Infisical Managed**: Use pre-deployed relays in select regions, shared across all Infisical Cloud organizations. Each organization traffic is isolated and encrypted. + - **Self-Deployed**: Deploy your own dedicated relay servers geographically close to your infrastructure for reduced latency. + + - ```bash - kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=gcp-id-token --from-literal=INFISICAL_MACHINE_IDENTITY_ID= - ``` - - - - The GCP IAM method is used to authenticate with Infisical with a GCP service account key. - - - - - Your machine identity ID. - - - Path to your GCP service account key file _(Must be in JSON format!)_ - - - The authentication method to use. Must be `gcp-iam` when using GCP IAM. - - - - - ```bash - kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=gcp-iam --from-literal=INFISICAL_MACHINE_IDENTITY_ID= --from-literal=INFISICAL_GCP_SERVICE_ACCOUNT_KEY_FILE_PATH= - ``` - - - - - The AWS IAM method is used to authenticate with Infisical with an AWS IAM role while running in an AWS environment like EC2, Lambda, etc. - - - - - Your machine identity ID. - - - The authentication method to use. Must be `aws-iam` when using Native AWS IAM. - - - - - ```bash - kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=aws-iam --from-literal=INFISICAL_MACHINE_IDENTITY_ID= - ``` - - - - The OIDC Auth method is used to authenticate with Infisical via identity tokens with OIDC. - - - - - Your machine identity ID. - - - The OIDC JWT from the identity provider. - - - The authentication method to use. Must be `oidc-auth` when using OIDC Auth. - - - - - ```bash - kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=oidc-auth --from-literal=INFISICAL_MACHINE_IDENTITY_ID= --from-literal=INFISICAL_JWT= - ``` - - - - The JWT Auth method is used to authenticate with Infisical via a JWT token. - - - - - The JWT token to use for authentication. - - - Your machine identity ID. - - - The authentication method to use. Must be `jwt-auth` when using JWT Auth. - - - - - ```bash - kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=jwt-auth --from-literal=INFISICAL_JWT= --from-literal=INFISICAL_MACHINE_IDENTITY_ID= - ``` - - - You can use the `INFISICAL_TOKEN` environment variable to authenticate with Infisical with a raw machine identity access token. - - - - - The machine identity access token to use for authentication. - - - - - ```bash - kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_TOKEN= - ``` - - - - - #### Required environment variables - - In addition to the authentication method above, you **must** include these required variables: - - - - The name of the relay server that this gateway should connect to. - - - The name of this gateway instance. - - - - **Complete example with required variables:** - ```bash - kubectl create secret generic infisical-gateway-environment \ - --from-literal=INFISICAL_AUTH_METHOD=universal-auth \ - --from-literal=INFISICAL_UNIVERSAL_AUTH_CLIENT_ID= \ - --from-literal=INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET= \ - --from-literal=INFISICAL_RELAY_NAME= \ - --from-literal=INFISICAL_GATEWAY_NAME= - ``` - - #### Other environment variables - - - - The API URL to use for the gateway. By default, `INFISICAL_API_URL` is set to `https://app.infisical.com`. - - - - ### Install the Infisical Gateway Helm Chart - - **Version mapping:** Helm chart versions `>= 1.0.0` contain the new Gateway v2 component. Helm chart versions `<= 0.0.5` contain the legacy Gateway v1 component. - - If you are moving from Gateway v1 (chart `<= 0.0.5`) to Gateway v2 (chart `>= 1.0.0`), this is not in-place. Gateway v2 provisions new gateway instances with new gateway IDs. Update any resources that reference a gateway ID (for example: dynamic secret configs, app connections, or other gateway-bound resources) to use the new Gateway v2 gateway ID. - - - ```bash - helm install infisical-gateway infisical-helm-charts/infisical-gateway - ``` - - ### Check the gateway logs - After installing the gateway, you can check the logs to ensure it's running as expected. - - ```bash - kubectl logs deployment/infisical-gateway - ``` - - You should see the following output which indicates the gateway is running as expected. - ```bash - $ kubectl logs deployment/infisical-gateway - 12:43AM INF Starting gateway - 12:43AM INF Starting gateway certificate renewal goroutine - 12:43AM INF Successfully registered gateway and received certificates - 12:43AM INF Connecting to relay server infisical-start on 152.42.218.156:2222... - 12:43AM INF Relay connection established for gateway - 12:43AM INF Received incoming connection, starting TLS handshake - 12:43AM INF TLS handshake completed successfully - 12:43AM INF Negotiated ALPN protocol: infisical-ping - 12:43AM INF Starting ping handler - 12:43AM INF Ping handler completed - 12:43AM INF Gateway is reachable by Infisical - ``` - - - - - For development or testing, you can run the Gateway directly. Log in with your machine identity and start the Gateway in one command: - ```bash - infisical gateway start --token $(infisical login --method=universal-auth --client-id=<> --client-secret=<> --plain) --relay= --name= - ``` - - Alternatively, if you already have the token, use it directly with the `--token` flag: - ```bash - infisical gateway start --token --relay= --name= - ``` - - Or set it as an environment variable: - ```bash - export INFISICAL_TOKEN= - infisical gateway start --relay= --name= - ``` - - - - For detailed information about the gateway commands and their options, see the [gateway command documentation](/cli/commands/gateway). +## How It Works - - **Requirements:** - - Ensure the deployed Gateway has network access to the private resources you intend to connect with Infisical - - The gateway must be able to reach the relay server (outbound connection only) - - Replace `` with the name of your relay server and `` with a unique name for this gateway - +The Gateway system uses SSH reverse tunnels for secure, firewall-friendly connectivity: - - - - To confirm your Gateway is working, check the deployment status by looking for the message **"Gateway started successfully"** in the Gateway logs. This indicates the Gateway is running properly. Next, verify its registration by opening your Infisical dashboard, navigating to **Organization Access Control**, and selecting the **Gateways** tab. Your newly deployed Gateway should appear in the list. - ![Gateway List](../../../images/platform/gateways/gateway-list.png) - - +1. **Gateway Registration**: The gateway establishes an outbound SSH reverse tunnel to a relay server using SSH certificates issued by Infisical +2. **Persistent Connection**: The gateway maintains an open TCP connection with the relay server, creating a secure channel for incoming requests +3. **Request Routing**: When Infisical needs to access your resources, requests are routed through the relay server to the already-established gateway connection +4. **Resource Access**: The gateway receives the routed requests and connects to your private resources on behalf of Infisical + +## Getting Started + +Ready to set up your gateway? Follow the guides below. + + + + Deploy and configure your gateway within your network infrastructure. + + + Set up relay servers if using self-deployed infrastructure. + + + + + Learn about the security model and implementation best practices. + + \ No newline at end of file diff --git a/docs/documentation/platform/gateways/relay-deployment.mdx b/docs/documentation/platform/gateways/relay-deployment.mdx new file mode 100644 index 0000000000..adf5fdb9de --- /dev/null +++ b/docs/documentation/platform/gateways/relay-deployment.mdx @@ -0,0 +1,243 @@ +--- +title: "Relay Deployment" +description: "How to deploy Infisical Relay Servers" +--- + +Infisical Relay is a secure routing layer that allows Infisical to connect to your private network resources, such as databases or internal APIs, without exposing them to the public internet. +The relay acts as an intermediary, forwarding encrypted traffic between Infisical and your deployed gateways. This ensures that your sensitive data remains protected and never leaves your network unencrypted. +With this architecture, you can achieve secure, firewall-friendly access across network boundaries, making it possible for Infisical to interact with resources even in highly restricted environments. + +Before diving in, it's important to determine whether you actually need to deploy your own relay server or if you can use Infisical's managed infrastructure. + +## Do You Need to Deploy a Relay? + +Not all users need to deploy their own relay servers. Infisical provides managed relay infrastructure in US/EU regions for Infisical Cloud users, which requires no setup or maintenance. You only need to deploy a relay if you: + +- Are self-hosting Infisical +- Have a dedicated enterprise instance of Infisical (managed by Infisical) +- Require closer geographic proximity to target resources than managed relays provide for lower latency and reduced network congestion when accessing resources through the relay +- Need full control over relay infrastructure and traffic routing + +If you are using Infisical Cloud and do not have specific requirements, you can use the managed relays provided by Infisical and skip the rest of this guide. + +## Deployment Steps + +To successfully deploy an Infisical Relay for use, follow these steps in order. + + + + Create a machine identity with the correct permissions to create and manage relays. This identity is used by the relay to authenticate with Infisical and should be provisioned in advance. + The relay supports several [machine identity auth methods](/documentation/platform/identities/machine-identities) for authentication, as listed below. Choose the one that best fits your environment and set the corresponding environment variables when deploying the relay. + + + + Simple and secure authentication using client ID and client secret. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=universal-auth` + - `INFISICAL_UNIVERSAL_AUTH_CLIENT_ID=` + - `INFISICAL_UNIVERSAL_AUTH_CLIENT_SECRET=` + + + + Direct authentication using a machine identity access token. + + **Environment Variables:** + - `INFISICAL_TOKEN=` + + + + Authentication using Kubernetes service account tokens. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=kubernetes` + - `INFISICAL_MACHINE_IDENTITY_ID=` + + + + Authentication using AWS IAM roles. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=aws-iam` + - `INFISICAL_MACHINE_IDENTITY_ID=` + + + + Authentication using GCP identity tokens. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=gcp-id-token` + - `INFISICAL_MACHINE_IDENTITY_ID=` + + + + Authentication using GCP service account keys. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=gcp-iam` + - `INFISICAL_MACHINE_IDENTITY_ID=` + - `INFISICAL_GCP_SERVICE_ACCOUNT_KEY_FILE_PATH=` + + + + Authentication using Azure managed identity. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=azure` + - `INFISICAL_MACHINE_IDENTITY_ID=` + + + + Authentication using OIDC identity tokens. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=oidc-auth` + - `INFISICAL_MACHINE_IDENTITY_ID=` + - `INFISICAL_JWT=` + + + + Authentication using JWT tokens. + + **Environment Variables:** + - `INFISICAL_AUTH_METHOD=jwt-auth` + - `INFISICAL_MACHINE_IDENTITY_ID=` + - `INFISICAL_JWT=` + + + + + + Install the Infisical CLI on the server where you plan to deploy the relay. The CLI is required for relay installation and management. + + See the [CLI Installation Guide](/cli/overview) for instructions. + + This server must have a static IP address or DNS name to be identifiable by the Infisical platform. + + + + + Ensure your network and firewall settings allow the server to accept inbound connections and make outbound connections: + + **Inbound Connections Rules:** + | Protocol | Source | Port | Purpose | + | -------- | ------------------ | ---- | -------------------------------- | + | TCP | Gateways | 2222 | SSH reverse tunnel establishment | + | TCP | Infisical instance host (US/EU, other) | 8443 | Platform-to-relay communication | + + **Outbound Connections Rules:** + | Protocol | Destination | Port | Purpose | + | -------- | ------------------------------------ | ---- | ------------------------------------------ | + | TCP | Infisical instance host (US/EU, other) | 443 | API communication and certificate requests | + + + + + The Infisical CLI is used to install and start the relay in your chosen environment. The CLI provides commands for both production and development scenarios, and supports a variety of options/flags to configure your deployment. + + To view all available flags and equivalent environment variables for relay deployment, see the [Relay CLI Command Reference](/cli/commands/relay). + + + For production deployments on Linux servers, install the Relay as a systemd service. This installation method only supports [Token Auth](/documentation/platform/identities/token-auth) at the moment. + + Once you have a [Token Auth](/documentation/platform/identities/token-auth) token, set the following environment variables for relay authentication: + + ```bash + export INFISICAL_TOKEN= + ``` + + + The systemd install command requires a Linux operating system with root/sudo privileges. + + + ```bash + sudo infisical relay systemd install \ + --token \ + --name \ + --domain \ + --host + + # Start the relay service + sudo systemctl start infisical-relay + sudo systemctl enable infisical-relay + ``` + + + + For non-Linux systems or when you need more control over the relay process: + + ```bash + infisical relay start \ + --type= \ + --host= \ + --name= \ + --auth-method= + ``` + + This method supports all [machine identity auth methods](/documentation/platform/identities/machine-identities) and runs in the foreground. Suitable for production use on non-Linux systems or development environments. + Set the appropriate environment variables for your chosen auth method as described in Step 1 before running the relay start command. + + + + + + + +## Frequently Asked Questions + + +No, relay servers cannot decrypt any traffic passing through them due to end-to-end encryption: + +- **Client-to-Gateway mTLS (via TLS-pinned tunnel)**: Clients connect via a proxy that establishes a TLS-pinned tunnel to the gateway; mTLS between the client and gateway is negotiated inside this tunnel, encrypting all application traffic +- **SSH tunnel encryption**: The mTLS-encrypted traffic is then transmitted through SSH reverse tunnels to relay servers +- **Double encryption**: Traffic is encrypted twice - once by client mTLS and again by SSH tunnels +- **Relay only routes traffic**: The relay server only routes the doubly-encrypted traffic without access to either encryption layer + +The relay infrastructure is designed as a secure routing mechanism where only the client and gateway can decrypt the actual application traffic. + + + + +Deploying your own relay provides several advantages: + +- **Dedicated resources**: Full control over relay infrastructure and performance +- **Lower latency**: Deploy closer to your gateways for optimal performance +- **Compliance**: Meet specific data routing and compliance requirements +- **Custom network policies**: Implement organization-specific network configurations +- **Geographic proximity**: Reduce network congestion and improve response times to access resources +- **High availability**: Deploy multiple relays for redundancy and load distribution + +Organization-deployed relays give you complete control over your secure communication infrastructure. + + + + +For detailed troubleshooting: + +**Platform cannot connect to relay:** + +- Check firewall rules allow inbound TCP with TLS on port 8443 +- Test connectivity: `openssl s_client -connect :8443` + +**Test network connectivity:** + +```bash +# Test outbound API access from relay. Replace URL with your Infisical instance if self-hosted +curl -I https://app.infisical.com + +# Test TCP with TLS port from platform +openssl s_client -connect :8443 +``` + + + +Relay server outages affect gateway connectivity: + +- **Gateway reconnection**: Gateways will automatically attempt to reconnect when the relay comes back online +- **Service interruption**: While the relay is down, the Infisical platform cannot reach gateways through that relay. As a result, any secrets or resources accessed via those gateways will be temporarily unavailable until connectivity is restored. +- **Multiple relays**: Deploy multiple relay servers for redundancy and high availability +- **Automatic restart**: Use systemd or container orchestration to automatically restart failed relay services + +For production environments, consider deploying multiple relay servers to avoid single points of failure. + + diff --git a/docs/documentation/platform/gateways/gateway-security.mdx b/docs/documentation/platform/gateways/security.mdx similarity index 91% rename from docs/documentation/platform/gateways/gateway-security.mdx rename to docs/documentation/platform/gateways/security.mdx index 6962c627e4..dc70aa36f0 100644 --- a/docs/documentation/platform/gateways/gateway-security.mdx +++ b/docs/documentation/platform/gateways/security.mdx @@ -1,13 +1,9 @@ --- -title: "Gateway Security Architecture" -sidebarTitle: "Architecture" -description: "Understand the security model and tenant isolation of Infisical's Gateway" +title: "Security Architecture" +description: "Security model, tenant isolation, and best practices for Infisical Gateways and Relays" --- -# Gateway Security Architecture - The Infisical Gateway enables secure access to private resources using SSH reverse tunnels, certificate-based authentication, and a comprehensive PKI (Public Key Infrastructure) system. The architecture provides end-to-end encryption and complete tenant isolation through multiple certificate authorities. -This document explains the internal security architecture and how tenant isolation is maintained. ## Security Model Overview @@ -82,16 +78,16 @@ The platform establishes secure direct connections with gateways through a **TLS 2. **Connection Flow**: ``` - Platform ←→ [SSH Reverse Tunnel] ←→ Gateway + Platform ←→ [TCP with TLS] ←→ Relay ←→ [SSH Reverse Tunnel] ←→ Gateway ``` - Gateway maintains persistent outbound SSH tunnel to relay server - - Platform connects directly to gateway through this tunnel - - TLS handshake occurs over the SSH tunnel, establishing mTLS connection - - Application traffic flows through the TLS-pinned tunnel + - Platform connects to relay server using TCP with TLS + - Relay routes encrypted traffic between platform and gateway + - TLS handshake occurs between platform and gateway through the relay + - Application traffic flows through the TLS-pinned tunnel via relay routing 3. **Security Benefits**: - - **No inbound connections**: Gateway never needs to accept incoming connections - **Certificate-based authentication**: Uses Organization Gateway certificates for mutual TLS - **Double encryption**: TLS traffic within SSH tunnel provides layered security @@ -132,7 +128,6 @@ The architecture provides tenant isolation through multiple certificate authorit - Ephemeral certificate validation ensures time-bound access 2. **Network Isolation**: - - Each organization's traffic flows through isolated certificate-authenticated channels - Relay servers route traffic based on certificate validation without content access - Gateway validates all incoming connections against Organization Gateway Client CA