From 12a943019f357f0810d57a18f7122eaccdf60964 Mon Sep 17 00:00:00 2001 From: Sheen Capadngan Date: Fri, 12 Sep 2025 03:34:12 +0800 Subject: [PATCH 01/12] misc: revamped gateway v2 docs --- docs/cli/commands/relay.mdx | 160 ++++++ docs/docs.json | 3 +- .../platform/gateways/deployment.mdx | 375 ++++++++++++++ .../platform/gateways/networking.mdx | 170 +++++- .../platform/gateways/overview.mdx | 488 +++--------------- .../{gateway-security.mdx => security.mdx} | 90 +++- 6 files changed, 849 insertions(+), 437 deletions(-) create mode 100644 docs/documentation/platform/gateways/deployment.mdx rename docs/documentation/platform/gateways/{gateway-security.mdx => security.mdx} (62%) diff --git a/docs/cli/commands/relay.mdx b/docs/cli/commands/relay.mdx index 46a061da3..66bed96da 100644 --- a/docs/cli/commands/relay.mdx +++ b/docs/cli/commands/relay.mdx @@ -9,6 +9,15 @@ description: "Relay-related commands for Infisical" infisical relay start --type= --host= --name= --auth-method= ``` + + ```bash + # Install systemd service + sudo infisical relay systemd install --type= --host= --name= --token= + + # Uninstall systemd service + sudo infisical relay systemd uninstall + ``` + ## Description @@ -304,3 +313,154 @@ The Infisical CLI supports multiple authentication methods for organization rela - You want full control over your relay infrastructure and its configuration + + + 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 --type= --host= --name= [flags] +``` + +#### 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. Requires `--relay-auth-secret` flag or `INFISICAL_RELAY_AUTH_SECRET` environment variable. + - **`org`**: Dedicated relay server that individual organizations deploy and manage in their own infrastructure. Requires `--token` flag. + +```bash +# Organization relay +sudo infisical relay systemd install --type=org --host=192.168.1.100 --name=my-org-relay --token= + +# Instance relay +sudo infisical relay systemd install --type=instance --host=10.0.1.50 --name=shared-relay --relay-auth-secret= +``` + + + + + 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 --type=org --name=my-relay --token= + +# Example with hostname +sudo infisical relay systemd install --host=relay.example.com --type=org --name=my-relay --token= +``` + + + + + The name of the relay. + +```bash +# Example +sudo infisical relay systemd install --name=my-relay --type=org --host=192.168.1.100 --token= +``` + + + + + Connect with Infisical using machine identity access token. Required for organization relays (`--type=org`). + +```bash +# Example +sudo infisical relay systemd install --token= --type=org --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= --type=org --host= --name= +``` + + + + + Relay auth secret. Required for instance relays (`--type=instance`) if the `INFISICAL_RELAY_AUTH_SECRET` environment variable is not set. + +```bash +# Example +sudo infisical relay systemd install --relay-auth-secret= --type=instance --host= --name= +``` + + + +#### Examples + +```bash +# Install organization relay with token authentication +sudo infisical relay systemd install --type=org --host=192.168.1.100 --name=my-org-relay --token= + +# Install instance relay with auth secret +sudo infisical relay systemd install --type=instance --host=10.0.1.50 --name=shared-relay --relay-auth-secret= + +# Install with custom domain +sudo infisical relay systemd install --domain=http://localhost:8080 --token= --type=org --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 +``` + + + + + Uninstall and remove systemd service for the relay. Must be run with sudo on Linux systems. + +```bash +sudo infisical relay systemd uninstall +``` + +#### Examples + +```bash +# Uninstall the relay systemd service +sudo infisical relay systemd uninstall +``` + +#### What it does + +- 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 285e11a60..c9c2527f4 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/deployment", "documentation/platform/gateways/networking", + "documentation/platform/gateways/security", { "group": "Gateway (Deprecated)", "pages": [ diff --git a/docs/documentation/platform/gateways/deployment.mdx b/docs/documentation/platform/gateways/deployment.mdx new file mode 100644 index 000000000..3f392dd22 --- /dev/null +++ b/docs/documentation/platform/gateways/deployment.mdx @@ -0,0 +1,375 @@ +--- +title: "Deployment Guide" +description: "Complete guide to deploying Infisical Gateways and Relays" +--- + +This guide covers everything you need to deploy and configure both Infisical Gateways and Relay Servers, including prerequisites, step-by-step instructions, and troubleshooting. + +## Prerequisites + +Before deploying gateways or relays, ensure you have: + +1. **Machine Identity** - Configured with appropriate permissions to create and manage gateways +2. **Network Access** - Proper connectivity between components +3. **Relay Server** - A running relay server before deploying gateways + +## Deploying Relays + +Choose the relay deployment type that best fits your needs: + +- **Instance Relays** - Use Infisical's managed infrastructure (Infisical Cloud) or shared relays set up by your instance administrator (self-hosted). Best for getting started quickly with minimal operational overhead. + +- **Organization Relays** - Deploy and manage your own relay servers. Choose this for lower latency, custom network policies, compliance requirements, or when you need full control over the relay infrastructure. + + + Most users should start with **Instance Relays** for simplicity. Consider + Organization Relays only if you have specific latency, compliance, or control + requirements. + + + + + **Infisical Cloud:** + - Pre-configured and ready to use + - No setup required, managed by Infisical + + **Self-hosted:** + + Instance relays require **two-step configuration** with matching secrets: + + **Step 1: Instance Admin Configuration** + The Infisical instance administrator must first set the relay auth secret in the instance environment: + + ```bash + # In the Infisical instance environment variables + RELAY_AUTH_SECRET= + ``` + + **Step 2: Relay Deployment** + Deploy the relay using the **same secret value**: + + ```bash + # Set the matching secret for relay deployment + export INFISICAL_RELAY_AUTH_SECRET= + + # Start the instance relay + infisical relay start --type=instance --host= --name= + ``` + + + The `RELAY_AUTH_SECRET` (instance environment) and + `INFISICAL_RELAY_AUTH_SECRET` (relay environment) **must match exactly** for + authentication to work. + + + + + + Deploy your own relay server for full control. Organization relays support all authentication methods: + + ```bash + # Token auth + infisical relay start --type=org --host= --name= --token= + + # Universal auth + infisical relay start --type=org --host= --name= --auth-method=universal-auth --client-id= --client-secret= + + # Other auth methods (kubernetes, aws-iam, gcp-id-token, azure, etc.) + infisical relay start --type=org --host= --name= --auth-method= --machine-identity-id= + ``` + + + + +### Relay Systemd Service (Linux) + +For production deployments, install as a systemd service: + +```bash +# Organization relay +sudo infisical relay systemd install --token= --name= --host= --type=org + +# Instance relay +sudo infisical relay systemd install --type=instance --name= --host= --relay-auth-secret= + +# Start the service +sudo systemctl start infisical-relay + +# Uninstall +sudo infisical relay systemd uninstall +``` + +**Required Network Configuration:** + +- **Inbound SSH** on port 2222 from gateways +- **Inbound TCP with TLS** on port 8443 from Infisical platform +- **Outbound HTTPS** to Infisical API endpoints on port 443 + +## Deploying Gateways + +### Linux Server Deployment + +For production deployments on Linux servers, 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 +- Automatically restarts on failure +- Starts on system boot +- Manages token and domain configuration securely in `/etc/infisical/gateway.conf` + + + The systemd install command requires a Linux operating system with root/sudo + privileges. + + +### Kubernetes Cluster Deployment + +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 +``` + + + **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. + + + +### Development & Testing + +For development or testing environments: + +```bash +# Direct execution with token +infisical gateway start --token --relay= --name= + +# Using environment variable +export INFISICAL_TOKEN= +infisical gateway start --relay= --name= +``` + +### Authentication Methods + +The gateway supports multiple authentication methods. Choose the one that best fits your environment: + + + + 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=` + + + +### Environment Variables + +In addition to authentication, you must set these required variables: + +- `INFISICAL_RELAY_NAME` - The name of the relay server to connect to +- `INFISICAL_GATEWAY_NAME` - A unique name for this gateway instance + +Optional variables: + +- `INFISICAL_API_URL` - The Infisical API URL (defaults to `https://app.infisical.com`) + +## Verification + +After deployment, verify your gateway is working: + +1. **Check logs** for "Gateway started successfully" message +2. **Verify registration** in the Infisical dashboard under Organization Access Control > Gateways +3. **Test connectivity** by creating a dynamic secret or app connection + +## Best Practices + +### Gateway Security + +- **One identity per gateway** - Create a unique machine identity for each gateway +- **Minimal permissions** - Assign only the permissions each gateway actually needs +- **Rotate credentials** - Set up regular credential rotation +- **Monitor authentication** - Watch for unusual authentication activity + +### Relay Security + +- **Secure secret management** - For instance relays, ensure `RELAY_AUTH_SECRET` and `INFISICAL_RELAY_AUTH_SECRET` are stored securely +- **Network isolation** - Use security groups and network ACLs to restrict relay access +- **Regular updates** - Keep relay servers updated and patched +- **Monitor traffic** - Watch for unusual connection patterns or traffic volume + +### Performance & Reliability + +- **Deploy close to resources** - Place gateways as close as possible to your private resources +- **Deploy relays strategically** - For organization relays, deploy close to gateways to minimize latency +- **Use multiple instances** - Deploy multiple gateways and relays for redundancy +- **Monitor resource usage** - Track CPU, memory, and network usage for both gateways and relays +- **Health monitoring** - Set up monitoring for both gateway and relay connection status +- **Automatic restart** - Use systemd or Kubernetes to automatically restart failed services + +## Troubleshooting + +### Common Issues + +**Gateway fails to start:** + +- Verify machine identity has correct permissions +- Check network connectivity to relay server +- Ensure all required environment variables are set + +**Cannot connect to relay:** + +- Verify relay server is running and accessible +- Check firewall rules allow outbound connections on port 2222 +- Confirm relay name matches exactly + +**Authentication failures:** + +- Verify machine identity credentials are correct +- Check token expiration and renewal +- Ensure authentication method is properly configured + +**Relay not accessible from gateways:** + +- Check firewall rules allow inbound SSH on port 2222 +- Verify public IP is correctly configured +- Test connectivity: `telnet 2222` + +**Platform cannot connect to relay:** + +- Check firewall rules allow inbound TCP with TLS on port 8443 +- Verify SSL certificate is properly configured +- Test connectivity: `openssl s_client -connect :8443` + +### Logs + +Check gateway logs for detailed error information: + +```bash +# systemd service +sudo journalctl -u infisical-gateway -f + +# Kubernetes +kubectl logs deployment/infisical-gateway + +# Local installation +# Logs appear in the terminal where you started the gateway +``` + +### Network Testing + +Test relay connectivity: + +```bash +# Test SSH port from gateway +nc -zv 2222 + +# Test TCP with TLS port from platform +openssl s_client -connect :8443 + +# Test outbound API access +curl -I https://app.infisical.com +``` diff --git a/docs/documentation/platform/gateways/networking.mdx b/docs/documentation/platform/gateways/networking.mdx index 2b068a535..5d6e235a7 100644 --- a/docs/documentation/platform/gateways/networking.mdx +++ b/docs/documentation/platform/gateways/networking.mdx @@ -1,21 +1,20 @@ --- -title: "Networking" -description: "Network configuration and firewall requirements for Infisical Gateway" +title: "Networking Requirements" +description: "Network configuration and firewall requirements for Infisical Gateways and Relays" --- -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. +This page outlines the required ports, protocols, and firewall configurations needed for optimal gateway and relay usage. ## Network Architecture -The gateway uses SSH reverse tunnels to establish secure connections with end-to-end encryption: +The gateway system 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 +## Gateway Network Requirements ### Outbound Connections (Required) @@ -55,6 +54,141 @@ The gateway requires the following outbound connectivity: +## Relay Server Network Requirements + +### Inbound Connections (Required) + +The relay server must accept the following inbound connections: + +| Protocol | Source | Port | Purpose | +| -------- | ------------------ | ---- | -------------------------------- | +| TCP | Gateways | 2222 | SSH reverse tunnel establishment | +| TCP | Infisical Platform | 8443 | Platform-to-relay communication | + +### Outbound Connections (Required) + +The relay server requires outbound connectivity to: + +| Protocol | Destination | Port | Purpose | +| -------- | ------------------------------------ | ---- | ------------------------------------------ | +| TCP | app.infisical.com / eu.infisical.com | 443 | API communication and certificate requests | + +## Firewall Configuration + +### Gateway Firewall Rules + +Since gateways only make outbound connections, 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 + +### Relay Firewall Rules + +Configure your firewall to allow: + +1. **SSH on port 2222** - For gateway connections + + ```bash + # Example iptables rule + iptables -A INPUT -p tcp --dport 2222 -j ACCEPT + ``` + +2. **TCP with TLS on port 8443** - For platform connections + + ```bash + # Example iptables rule + iptables -A INPUT -p tcp --dport 8443 -j ACCEPT + ``` + +3. **HTTPS to Infisical API** - For certificate requests and API communication + ```bash + # Example iptables rule + iptables -A OUTPUT -p tcp --dport 443 -d app.infisical.com -j ACCEPT + ``` + +## Cloud Provider Configuration + +### AWS EC2 + +Configure security groups: + +```json +{ + "SecurityGroupRules": [ + { + "IpProtocol": "tcp", + "FromPort": 2222, + "ToPort": 2222, + "CidrIpv4": "0.0.0.0/0", + "Description": "SSH for gateway connections" + }, + { + "IpProtocol": "tcp", + "FromPort": 8443, + "ToPort": 8443, + "CidrIpv4": "0.0.0.0/0", + "Description": "TCP with TLS for platform connections" + } + ] +} +``` + +### Google Cloud Platform + +Configure firewall rules: + +```bash +# Allow SSH from gateways +gcloud compute firewall-rules create allow-gateway-ssh \ + --allow tcp:2222 \ + --source-ranges 0.0.0.0/0 \ + --description "Allow SSH from gateways" + +# Allow TCP with TLS from platform +gcloud compute firewall-rules create allow-platform-tls \ + --allow tcp:8443 \ + --source-ranges 0.0.0.0/0 \ + --description "Allow TCP with TLS from platform" +``` + +### Azure + +Configure Network Security Groups: + +```json +{ + "securityRules": [ + { + "name": "AllowGatewaySSH", + "properties": { + "protocol": "Tcp", + "sourcePortRange": "*", + "destinationPortRange": "2222", + "sourceAddressPrefix": "*", + "destinationAddressPrefix": "*", + "access": "Allow", + "priority": 100, + "direction": "Inbound" + } + }, + { + "name": "AllowPlatformTLS", + "properties": { + "protocol": "Tcp", + "sourcePortRange": "*", + "destinationPortRange": "8443", + "sourceAddressPrefix": "*", + "destinationAddressPrefix": "*", + "access": "Allow", + "priority": 110, + "direction": "Inbound" + } + } + ] +} +``` + ## Protocol Details ### SSH over TCP @@ -65,10 +199,6 @@ The gateway uses SSH reverse tunnels for primary communication: - **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: @@ -78,14 +208,6 @@ SSH connections over TCP are stateful and handled seamlessly by all modern firew - **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 @@ -105,6 +227,15 @@ Configure security groups to allow: - **Outbound HTTPS** to app.infisical.com/eu.infisical.com on port 443 - **No inbound rules required** - SSH reverse tunnels are outbound only +## Performance Considerations + +### Network Optimization + +- **Deploy close to gateways** - Reduce latency by placing relay servers geographically close to your gateways +- **Use high-bandwidth connections** - Ensure adequate bandwidth for encrypted traffic +- **Monitor network performance** - Track latency and throughput metrics +- **Consider multiple relays** - Deploy multiple relay servers for redundancy and load distribution + ## Frequently Asked Questions @@ -134,7 +265,7 @@ TCP's reliability and firewall compatibility make it ideal for enterprise enviro -No inbound ports need to be opened. The gateway only makes outbound connections: +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 @@ -163,6 +294,7 @@ The gateway connects to **one relay server**: - **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: diff --git a/docs/documentation/platform/gateways/overview.mdx b/docs/documentation/platform/gateways/overview.mdx index b8ea0102a..84ca46d5f 100644 --- a/docs/documentation/platform/gateways/overview.mdx +++ b/docs/documentation/platform/gateways/overview.mdx @@ -1,5 +1,5 @@ --- -title: "Gateway" +title: "Gateway Overview" sidebarTitle: "Overview" description: "How to access private network resources from Infisical" --- @@ -8,13 +8,6 @@ description: "How to access private network resources from Infisical" 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. - Gateway is a paid feature available under the Enterprise Tier for Infisical Cloud users. Self-hosted Infisical users can contact @@ -22,6 +15,26 @@ Common use cases include generating dynamic credentials or rotating credentials license. +## What are Gateways and Relays? + +### Gateway + +A lightweight service deployed within your VPCs that provides secure access to private resources: + +- **Runs inside your network** - Deployed within your VPCs, data centers, or on-premises infrastructure +- **Makes outbound connections only** - No inbound firewall rules required +- **Provides secure access** - Uses SSH reverse tunnels and certificate-based authentication +- **Handles resource connections** - Connects to your private databases, APIs, and services + +### Relay Server + +Infrastructure that routes encrypted traffic between the Infisical platform and gateways: + +- **Routes encrypted traffic** - Routes traffic between the platform and gateways +- **Provides network isolation** - Enables communication without direct connections +- **Handles authentication** - Manages SSH certificate validation and routing +- **Ensures security** - Uses double encryption to protect data in transit + ## How It Works The Gateway system uses SSH reverse tunnels for secure, firewall-friendly connectivity: @@ -37,7 +50,62 @@ The Gateway system uses SSH reverse tunnels for secure, firewall-friendly connec - **Certificate-based authentication** provides enhanced security - **Automatic reconnection** if connections are lost -## Deployment +## Relay Types + +### Instance Relays (Shared Infrastructure) + +**Infisical Cloud:** + +- Pre-configured and ready to use +- No setup required +- Shared across all organizations +- Managed by Infisical + +**Self-hosted:** + +- Set up by instance administrators +- Shared across all organizations on the instance +- Uses `INFISICAL_RELAY_AUTH_SECRET` for authentication + +### Organization Relays (Customer-Deployed) + +**Benefits:** + +- Full control over infrastructure +- Lower latency (deploy closer to resources) +- Enhanced security and compliance +- Custom network policies + +**Authentication:** + +- Uses standard Infisical authentication methods +- Organization-specific credentials +- Full control over access and permissions + +## When to Use Each + +**Use Instance Relays when:** + +- You want minimal operational overhead +- You don't need custom network policies +- You're okay with shared infrastructure +- You want to get started quickly + +**Use Organization Relays when:** + +- You need lower latency +- You have security or compliance requirements +- You need custom network policies +- You want full control over infrastructure + +## Common Use Cases + +- **Database credential rotation** - Automatically rotate database passwords +- **Dynamic secret generation** - Generate temporary credentials for services +- **Private API access** - Connect to internal APIs and services +- **Compliance requirements** - Meet data sovereignty and air-gapped environment needs + +## Quick Start 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. @@ -45,405 +113,15 @@ For detailed installation instructions, refer to the Infisical [CLI Installation **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 +1. **Relay Server**: Before deploying gateways, you need a running relay server 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 +## Next Steps - - - 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). - +Ready to get started? Follow these guides: - - 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. - - - - - 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. - - - - - - ```bash - kubectl create secret generic infisical-gateway-environment --from-literal=INFISICAL_AUTH_METHOD=kubernetes --from-literal=INFISICAL_MACHINE_IDENTITY_ID= - ``` - - - - The Native Azure method is used to authenticate with Infisical when running in an Azure environment. - - - - - Your machine identity ID. - - - The authentication method to use. Must be `azure` when using Native Azure. - - - - - ```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. - - - - - Your machine identity ID. - - - The authentication method to use. Must be `gcp-id-token` when using Native GCP ID Token. - - - - - ```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). - - - **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 - - - - - - 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. **[Deployment Guide](/documentation/platform/gateways/deployment)** - Complete deployment instructions +2. **[Networking Requirements](/documentation/platform/gateways/networking)** - Network configuration and firewall setup +3. **[Security Architecture](/documentation/platform/gateways/security)** - Security model and best practices diff --git a/docs/documentation/platform/gateways/gateway-security.mdx b/docs/documentation/platform/gateways/security.mdx similarity index 62% rename from docs/documentation/platform/gateways/gateway-security.mdx rename to docs/documentation/platform/gateways/security.mdx index 6962c627e..db2c25f40 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,77 @@ 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 + +## Security Best Practices + +### Gateway Security + +- **One identity per gateway** - Create a unique machine identity for each gateway +- **Minimal permissions** - Assign only the permissions each gateway actually needs +- **Rotate credentials** - Set up regular credential rotation (quarterly recommended) +- **Monitor authentication** - Watch for unusual authentication activity +- **Deploy close to resources** - Place gateways as close as possible to your private resources +- **Use multiple gateways** - Deploy multiple gateways for redundancy and load distribution + +### Relay Security + +- **Deploy close to gateways** - Minimize latency between gateways and relays +- **Use multiple regions** - Deploy relays in multiple regions for redundancy +- **Monitor performance** - Track connection counts and throughput +- **Regular updates** - Keep relay servers updated and patched +- **Network isolation** - Use security groups and network ACLs to restrict access +- **Monitor network traffic** - Watch for unusual patterns + +### Network Security + +- **Gateway outbound only** - Gateways only need outbound connections (port 2222 to relays, port 443 to Infisical API) +- **Relay inbound** - Relays need inbound SSH (2222) and TCP with TLS (8443) +- **No inbound for gateways** - Never open inbound ports for gateways +- **Use security groups** in cloud environments to restrict access +- **Implement network ACLs** to limit traffic to specific IP ranges +- **Monitor network traffic** for unusual patterns +- **Regular security updates** for the relay server + +## Compliance Considerations + +### Data Sovereignty + +- **Customer-deployed relays** - Deploy relays in your preferred geographic region +- **Air-gapped environments** - Use self-hosted relays for completely isolated deployments +- **Custom network policies** - Implement organization-specific security requirements + +### Security Controls + +- **Certificate-based authentication** - No shared secrets, uses SSH certificates +- **End-to-end encryption** - All traffic is encrypted in transit +- **Tenant isolation** - Each organization's traffic is completely isolated +- **No data storage** - Relay servers only route traffic, never store data +- **Automatic reconnection** - Handles network interruptions gracefully + +## Troubleshooting Security Issues + +### Common Security Issues + +**Authentication failures:** + +- Verify machine identity credentials are correct +- Check token expiration and renewal +- Ensure authentication method is properly configured + +**Network security issues:** + +- Verify firewall rules allow required connections +- Check for network ACLs blocking traffic +- Monitor for unusual network patterns + +### Security Monitoring + +**Key metrics to monitor:** + +- Gateway connection status and health +- Authentication success/failure rates +- Network connectivity and latency +- Unusual traffic patterns or access attempts From 499946c042777e9f4507a8b6fe8da3e8fc05bedb Mon Sep 17 00:00:00 2001 From: Sheen Capadngan Date: Fri, 12 Sep 2025 21:09:13 +0800 Subject: [PATCH 02/12] misc: addressed comments --- docs/cli/commands/gateway.mdx | 2 +- docs/cli/commands/relay.mdx | 2 +- docs/docs.json | 4 +- ...{deployment.mdx => gateway-deployment.mdx} | 262 ++++++----- .../platform/gateways/networking.mdx | 310 ------------- .../platform/gateways/overview.mdx | 87 ++-- .../platform/gateways/relay-deployment.mdx | 424 ++++++++++++++++++ 7 files changed, 586 insertions(+), 505 deletions(-) rename docs/documentation/platform/gateways/{deployment.mdx => gateway-deployment.mdx} (50%) delete mode 100644 docs/documentation/platform/gateways/networking.mdx create mode 100644 docs/documentation/platform/gateways/relay-deployment.mdx diff --git a/docs/cli/commands/gateway.mdx b/docs/cli/commands/gateway.mdx index 99d0e1086..4ae660cf5 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= ``` diff --git a/docs/cli/commands/relay.mdx b/docs/cli/commands/relay.mdx index 66bed96da..7530ee99d 100644 --- a/docs/cli/commands/relay.mdx +++ b/docs/cli/commands/relay.mdx @@ -9,7 +9,7 @@ description: "Relay-related commands for Infisical" infisical relay start --type= --host= --name= --auth-method= ``` - + ```bash # Install systemd service sudo infisical relay systemd install --type= --host= --name= --token= diff --git a/docs/docs.json b/docs/docs.json index c9c2527f4..9eeeea500 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -173,8 +173,8 @@ "group": "Gateway", "pages": [ "documentation/platform/gateways/overview", - "documentation/platform/gateways/deployment", - "documentation/platform/gateways/networking", + "documentation/platform/gateways/gateway-deployment", + "documentation/platform/gateways/relay-deployment", "documentation/platform/gateways/security", { "group": "Gateway (Deprecated)", diff --git a/docs/documentation/platform/gateways/deployment.mdx b/docs/documentation/platform/gateways/gateway-deployment.mdx similarity index 50% rename from docs/documentation/platform/gateways/deployment.mdx rename to docs/documentation/platform/gateways/gateway-deployment.mdx index 3f392dd22..f939744c3 100644 --- a/docs/documentation/platform/gateways/deployment.mdx +++ b/docs/documentation/platform/gateways/gateway-deployment.mdx @@ -1,120 +1,27 @@ --- -title: "Deployment Guide" -description: "Complete guide to deploying Infisical Gateways and Relays" +title: "Gateway Deployment" +description: "Complete guide to deploying Infisical Gateways including network configuration and firewall requirements" --- -This guide covers everything you need to deploy and configure both Infisical Gateways and Relay Servers, including prerequisites, step-by-step instructions, and troubleshooting. +This guide covers everything you need to deploy and configure Infisical Gateways, including prerequisites, step-by-step deployment instructions, network configuration, and troubleshooting. ## Prerequisites -Before deploying gateways or relays, ensure you have: +Before deploying gateways, ensure you have: 1. **Machine Identity** - Configured with appropriate permissions to create and manage gateways -2. **Network Access** - Proper connectivity between components -3. **Relay Server** - A running relay server before deploying gateways +2. **Relay Server** - A running relay server before deploying gateways. This can be either a managed relay (like Infisical's US/EU relays) or your own self-deployed relay server (see [Relay Deployment Guide](/documentation/platform/gateways/relay-deployment)) -## Deploying Relays +## Gateway Deployment Methods -Choose the relay deployment type that best fits your needs: - -- **Instance Relays** - Use Infisical's managed infrastructure (Infisical Cloud) or shared relays set up by your instance administrator (self-hosted). Best for getting started quickly with minimal operational overhead. - -- **Organization Relays** - Deploy and manage your own relay servers. Choose this for lower latency, custom network policies, compliance requirements, or when you need full control over the relay infrastructure. - - - Most users should start with **Instance Relays** for simplicity. Consider - Organization Relays only if you have specific latency, compliance, or control - requirements. - - - - - **Infisical Cloud:** - - Pre-configured and ready to use - - No setup required, managed by Infisical - - **Self-hosted:** - - Instance relays require **two-step configuration** with matching secrets: - - **Step 1: Instance Admin Configuration** - The Infisical instance administrator must first set the relay auth secret in the instance environment: - - ```bash - # In the Infisical instance environment variables - RELAY_AUTH_SECRET= - ``` - - **Step 2: Relay Deployment** - Deploy the relay using the **same secret value**: - - ```bash - # Set the matching secret for relay deployment - export INFISICAL_RELAY_AUTH_SECRET= - - # Start the instance relay - infisical relay start --type=instance --host= --name= - ``` - - - The `RELAY_AUTH_SECRET` (instance environment) and - `INFISICAL_RELAY_AUTH_SECRET` (relay environment) **must match exactly** for - authentication to work. - - - - - - Deploy your own relay server for full control. Organization relays support all authentication methods: - - ```bash - # Token auth - infisical relay start --type=org --host= --name= --token= - - # Universal auth - infisical relay start --type=org --host= --name= --auth-method=universal-auth --client-id= --client-secret= - - # Other auth methods (kubernetes, aws-iam, gcp-id-token, azure, etc.) - infisical relay start --type=org --host= --name= --auth-method= --machine-identity-id= - ``` - - - - -### Relay Systemd Service (Linux) - -For production deployments, install as a systemd service: - -```bash -# Organization relay -sudo infisical relay systemd install --token= --name= --host= --type=org - -# Instance relay -sudo infisical relay systemd install --type=instance --name= --host= --relay-auth-secret= - -# Start the service -sudo systemctl start infisical-relay - -# Uninstall -sudo infisical relay systemd uninstall -``` - -**Required Network Configuration:** - -- **Inbound SSH** on port 2222 from gateways -- **Inbound TCP with TLS** on port 8443 from Infisical platform -- **Outbound HTTPS** to Infisical API endpoints on port 443 - -## Deploying Gateways - -### Linux Server Deployment +### Linux Server Deployment (Production) For production deployments on Linux servers, 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. +If you are migrating from Gateway v1 (legacy `infisical gateway install` command), this will create a completely new gateway rather than upgrading your existing one. Gateway v2 provisions new gateway instances with new gateway IDs. You'll need to update any resources that reference the old gateway ID (for example: dynamic secret configs, app connections, or other gateway-bound resources) to use the new Gateway v2 gateway ID. @@ -135,7 +42,7 @@ This will install and start the Gateway as a secure systemd service that: privileges. -### Kubernetes Cluster Deployment +### Kubernetes Cluster Deployment (Production) For production deployments on Kubernetes clusters, install the Gateway using the Infisical Helm chart: @@ -168,7 +75,7 @@ helm install infisical-gateway infisical-helm-charts/infisical-gateway **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. +If you are moving from Gateway v1 (chart `<= 0.0.5`) to Gateway v2 (chart `>= 1.0.0`), this will create a completely new gateway rather than upgrading your existing one. Gateway v2 provisions new gateway instances with new gateway IDs. You'll need to update any resources that reference the old gateway ID (for example: dynamic secret configs, app connections, or other gateway-bound resources) to use the new Gateway v2 gateway ID. @@ -185,7 +92,7 @@ export INFISICAL_TOKEN= infisical gateway start --relay= --name= ``` -### Authentication Methods +## Authentication Methods The gateway supports multiple authentication methods. Choose the one that best fits your environment: @@ -266,7 +173,7 @@ The gateway supports multiple authentication methods. Choose the one that best f -### Environment Variables +## Environment Variables In addition to authentication, you must set these required variables: @@ -277,6 +184,72 @@ Optional variables: - `INFISICAL_API_URL` - The Infisical API URL (defaults to `https://app.infisical.com`) +## Network Configuration + +### Gateway Network Requirements + +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 via the relay servers 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 + +### 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 + +Your gateway needs to connect to a relay server on port 2222. The specific relay server depends on your setup: + +**Managed Relays (Infisical Cloud):** + +- Use Infisical's pre-configured relay servers in US/EU regions +- Static IP addresses available for firewall whitelisting +- Allow outbound TCP connections to the relay server IP on port 2222 + +**Self-Deployed or Instance Relays:** + +- Connect to your own relay server or relay servers deployed by your instance administrator +- Allow outbound TCP connections to your relay server IP/hostname on port 2222 +- Example: If your relay is at `203.0.113.100`, allow TCP to `203.0.113.100:2222` +- For instance relays, contact your admin for the specific relay server addresses + +## Firewall Configuration + +### Gateway Firewall Rules + +Since gateways only make outbound connections, 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 + ## Verification After deployment, verify your gateway is working: @@ -294,20 +267,12 @@ After deployment, verify your gateway is working: - **Rotate credentials** - Set up regular credential rotation - **Monitor authentication** - Watch for unusual authentication activity -### Relay Security - -- **Secure secret management** - For instance relays, ensure `RELAY_AUTH_SECRET` and `INFISICAL_RELAY_AUTH_SECRET` are stored securely -- **Network isolation** - Use security groups and network ACLs to restrict relay access -- **Regular updates** - Keep relay servers updated and patched -- **Monitor traffic** - Watch for unusual connection patterns or traffic volume - ### Performance & Reliability - **Deploy close to resources** - Place gateways as close as possible to your private resources -- **Deploy relays strategically** - For organization relays, deploy close to gateways to minimize latency -- **Use multiple instances** - Deploy multiple gateways and relays for redundancy -- **Monitor resource usage** - Track CPU, memory, and network usage for both gateways and relays -- **Health monitoring** - Set up monitoring for both gateway and relay connection status +- **Use multiple instances** - Deploy multiple gateways for redundancy +- **Monitor resource usage** - Track CPU, memory, and network usage for gateways +- **Health monitoring** - Set up monitoring for gateway connection status - **Automatic restart** - Use systemd or Kubernetes to automatically restart failed services ## Troubleshooting @@ -332,18 +297,6 @@ After deployment, verify your gateway is working: - Check token expiration and renewal - Ensure authentication method is properly configured -**Relay not accessible from gateways:** - -- Check firewall rules allow inbound SSH on port 2222 -- Verify public IP is correctly configured -- Test connectivity: `telnet 2222` - -**Platform cannot connect to relay:** - -- Check firewall rules allow inbound TCP with TLS on port 8443 -- Verify SSL certificate is properly configured -- Test connectivity: `openssl s_client -connect :8443` - ### Logs Check gateway logs for detailed error information: @@ -361,15 +314,58 @@ kubectl logs deployment/infisical-gateway ### Network Testing -Test relay connectivity: +Test relay connectivity from gateway: ```bash -# Test SSH port from gateway +# Test SSH port to relay nc -zv 2222 -# Test TCP with TLS port from platform -openssl s_client -connect :8443 - # Test outbound API access curl -I https://app.infisical.com ``` + +## 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. + + + + +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. + + + + +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 + + diff --git a/docs/documentation/platform/gateways/networking.mdx b/docs/documentation/platform/gateways/networking.mdx deleted file mode 100644 index 5d6e235a7..000000000 --- a/docs/documentation/platform/gateways/networking.mdx +++ /dev/null @@ -1,310 +0,0 @@ ---- -title: "Networking Requirements" -description: "Network configuration and firewall requirements for Infisical Gateways and Relays" ---- - -This page outlines the required ports, protocols, and firewall configurations needed for optimal gateway and relay usage. - -## Network Architecture - -The gateway system 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 - -## Gateway Network Requirements - -### 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. - - - -## Relay Server Network Requirements - -### Inbound Connections (Required) - -The relay server must accept the following inbound connections: - -| Protocol | Source | Port | Purpose | -| -------- | ------------------ | ---- | -------------------------------- | -| TCP | Gateways | 2222 | SSH reverse tunnel establishment | -| TCP | Infisical Platform | 8443 | Platform-to-relay communication | - -### Outbound Connections (Required) - -The relay server requires outbound connectivity to: - -| Protocol | Destination | Port | Purpose | -| -------- | ------------------------------------ | ---- | ------------------------------------------ | -| TCP | app.infisical.com / eu.infisical.com | 443 | API communication and certificate requests | - -## Firewall Configuration - -### Gateway Firewall Rules - -Since gateways only make outbound connections, 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 - -### Relay Firewall Rules - -Configure your firewall to allow: - -1. **SSH on port 2222** - For gateway connections - - ```bash - # Example iptables rule - iptables -A INPUT -p tcp --dport 2222 -j ACCEPT - ``` - -2. **TCP with TLS on port 8443** - For platform connections - - ```bash - # Example iptables rule - iptables -A INPUT -p tcp --dport 8443 -j ACCEPT - ``` - -3. **HTTPS to Infisical API** - For certificate requests and API communication - ```bash - # Example iptables rule - iptables -A OUTPUT -p tcp --dport 443 -d app.infisical.com -j ACCEPT - ``` - -## Cloud Provider Configuration - -### AWS EC2 - -Configure security groups: - -```json -{ - "SecurityGroupRules": [ - { - "IpProtocol": "tcp", - "FromPort": 2222, - "ToPort": 2222, - "CidrIpv4": "0.0.0.0/0", - "Description": "SSH for gateway connections" - }, - { - "IpProtocol": "tcp", - "FromPort": 8443, - "ToPort": 8443, - "CidrIpv4": "0.0.0.0/0", - "Description": "TCP with TLS for platform connections" - } - ] -} -``` - -### Google Cloud Platform - -Configure firewall rules: - -```bash -# Allow SSH from gateways -gcloud compute firewall-rules create allow-gateway-ssh \ - --allow tcp:2222 \ - --source-ranges 0.0.0.0/0 \ - --description "Allow SSH from gateways" - -# Allow TCP with TLS from platform -gcloud compute firewall-rules create allow-platform-tls \ - --allow tcp:8443 \ - --source-ranges 0.0.0.0/0 \ - --description "Allow TCP with TLS from platform" -``` - -### Azure - -Configure Network Security Groups: - -```json -{ - "securityRules": [ - { - "name": "AllowGatewaySSH", - "properties": { - "protocol": "Tcp", - "sourcePortRange": "*", - "destinationPortRange": "2222", - "sourceAddressPrefix": "*", - "destinationAddressPrefix": "*", - "access": "Allow", - "priority": 100, - "direction": "Inbound" - } - }, - { - "name": "AllowPlatformTLS", - "properties": { - "protocol": "Tcp", - "sourcePortRange": "*", - "destinationPortRange": "8443", - "sourceAddressPrefix": "*", - "destinationAddressPrefix": "*", - "access": "Allow", - "priority": 110, - "direction": "Inbound" - } - } - ] -} -``` - -## 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 - -### 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 - -## 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 - -## Performance Considerations - -### Network Optimization - -- **Deploy close to gateways** - Reduce latency by placing relay servers geographically close to your gateways -- **Use high-bandwidth connections** - Ensure adequate bandwidth for encrypted traffic -- **Monitor network performance** - Track latency and throughput metrics -- **Consider multiple relays** - Deploy multiple relay servers for redundancy and load distribution - -## 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 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. - - - - -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 84ca46d5f..266f2ad16 100644 --- a/docs/documentation/platform/gateways/overview.mdx +++ b/docs/documentation/platform/gateways/overview.mdx @@ -50,78 +50,49 @@ The Gateway system uses SSH reverse tunnels for secure, firewall-friendly connec - **Certificate-based authentication** provides enhanced security - **Automatic reconnection** if connections are lost -## Relay Types +## Understanding Relay Types -### Instance Relays (Shared Infrastructure) +Relays are the routing infrastructure that enables secure communication between Infisical and your gateways. There are two main approaches to relay deployment: -**Infisical Cloud:** +**Managed Relays** - Use Infisical's hosted relay infrastructure in US/EU regions for quick setup with minimal operational overhead. -- Pre-configured and ready to use -- No setup required -- Shared across all organizations -- Managed by Infisical +**Self-Deployed Relays** - Deploy your own relay servers for regional proximity, enhanced control, and custom network policies. -**Self-hosted:** +### Managed Relays (Recommended for Most Users) -- Set up by instance administrators -- Shared across all organizations on the instance -- Uses `INFISICAL_RELAY_AUTH_SECRET` for authentication +Managed relays are pre-configured relay servers hosted by Infisical that can serve multiple organizations with minimal operational overhead. -### Organization Relays (Customer-Deployed) +**Infisical Cloud (US/EU Regions):** -**Benefits:** +- Pre-configured relays in US and EU regions +- No setup or maintenance required +- Shared across all Infisical Cloud organizations +- Managed and monitored by Infisical +- Best for getting started quickly -- Full control over infrastructure -- Lower latency (deploy closer to resources) -- Enhanced security and compliance -- Custom network policies +**Self-Hosted Instance Relays:** -**Authentication:** +- Instance administrators can deploy shared relays for their entire instance +- All organizations on the instance can use these relays +- Reduces operational burden for individual Organizations +- Ideal for self-hosted instances wanting shared relay infrastructure +### Self-Deployed Relays (Organization-Specific) + +Organizations can deploy and manage their own dedicated relay servers for regional proximity, network control, compliance requirements, or enhanced security. + +**Key Benefits:** + +- Deploy in any region or cloud provider for lower latency +- Custom network configurations and security policies +- Dedicated resources not shared with other organizations +- Full control over relay infrastructure - Uses standard Infisical authentication methods -- Organization-specific credentials -- Full control over access and permissions - -## When to Use Each - -**Use Instance Relays when:** - -- You want minimal operational overhead -- You don't need custom network policies -- You're okay with shared infrastructure -- You want to get started quickly - -**Use Organization Relays when:** - -- You need lower latency -- You have security or compliance requirements -- You need custom network policies -- You want full control over infrastructure - -## Common Use Cases - -- **Database credential rotation** - Automatically rotate database passwords -- **Dynamic secret generation** - Generate temporary credentials for services -- **Private API access** - Connect to internal APIs and services -- **Compliance requirements** - Meet data sovereignty and air-gapped environment needs - -## Quick Start - -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 -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. ## Next Steps Ready to get started? Follow these guides: -1. **[Deployment Guide](/documentation/platform/gateways/deployment)** - Complete deployment instructions -2. **[Networking Requirements](/documentation/platform/gateways/networking)** - Network configuration and firewall setup +1. **[Gateway Deployment](/documentation/platform/gateways/gateway-deployment)** - Complete gateway deployment and network configuration +2. **[Relay Deployment](/documentation/platform/gateways/relay-deployment)** - Complete relay deployment and network configuration 3. **[Security Architecture](/documentation/platform/gateways/security)** - Security model and best practices diff --git a/docs/documentation/platform/gateways/relay-deployment.mdx b/docs/documentation/platform/gateways/relay-deployment.mdx new file mode 100644 index 000000000..c90576d46 --- /dev/null +++ b/docs/documentation/platform/gateways/relay-deployment.mdx @@ -0,0 +1,424 @@ +--- +title: "Relay Deployment" +description: "Complete guide to deploying Infisical Relay Servers including network configuration and firewall requirements" +--- + +This guide covers everything you need to deploy and configure Infisical Relay Servers, including prerequisites, step-by-step deployment instructions, network configuration, and troubleshooting. + +## Prerequisites + +Before deploying relays, ensure you have: + +1. **Server Infrastructure** - A server or cloud instance to host the relay +2. **Network Connectivity** - Ability to accept inbound connections on ports 2222 and 8443, plus outbound HTTPS access to Infisical API +3. **Machine Identity** - Only required for organization relays; configured with appropriate permissions to create and manage relays + + + **Instance relays** don't require machine identities - they use a shared + secret configured by the instance administrator. + + +## Understanding Relay Types + +Relays are the routing infrastructure that enables secure communication between Infisical and your gateways. There are two main approaches to relay deployment: + +**Managed Relays** - Use Infisical's hosted relay infrastructure in US/EU regions for quick setup with minimal operational overhead. + +**Self-Deployed Relays** - Deploy your own relay servers for regional proximity, enhanced control, and custom network policies. + +### Managed Relays (Recommended for Most Users) + +Managed relays are pre-configured relay servers hosted by Infisical that can serve multiple organizations with minimal operational overhead. + +**Infisical Cloud (US/EU Regions):** + +- Pre-configured relays in US and EU regions +- No setup or maintenance required +- Shared across all Infisical Cloud organizations +- Managed and monitored by Infisical +- Best for getting started quickly + +**Self-Hosted Instance Relays:** + +- Instance administrators can deploy shared relays for their entire instance +- All organizations on the instance can use these relays +- Reduces operational burden for individual Organizations +- Ideal for self-hosted instances wanting shared relay infrastructure + +### Self-Deployed Relays (Organization-Specific) + +Organizations can deploy and manage their own dedicated relay servers for regional proximity, network control, compliance requirements, or enhanced security. + +**Key Benefits:** + +- Deploy in any region or cloud provider for lower latency +- Custom network configurations and security policies +- Dedicated resources not shared with other organizations +- Full control over relay infrastructure +- Uses standard Infisical authentication methods + +## Relay Deployment Methods + +If you've decided to deploy your own relay servers, choose the deployment type that best fits your needs: + +- **Instance Relays** - Deploy shared relays for your entire self-hosted Infisical instance. All organizations on the instance can use these relays without deploying their own. + +- **Organization Relays** - Deploy and manage your own dedicated relay servers. Choose this for lower latency, custom network policies, compliance requirements, or when you need full control over the relay infrastructure. + + + **Note:** If you're using Infisical Cloud, you likely don't need to deploy + relays at all - you can use the managed US/EU relays. This guide is for users + who need to deploy their own relay infrastructure. + + + + + Instance relays require **two-step configuration** with matching secrets: + + **Step 1: Instance Admin Configuration** + + The Infisical instance administrator must first set the relay auth secret in the instance environment: + + ```bash + # In the Infisical instance environment variables + RELAY_AUTH_SECRET= + ``` + + **Step 2: Relay Deployment** + + Deploy the relay using the **same secret value**: + + ```bash + # Set the matching secret for relay deployment + export INFISICAL_RELAY_AUTH_SECRET= + + # Start the instance relay + infisical relay start --type=instance --host= --name= + ``` + + **Install as daemon (Linux only):** + + ```bash + # Instance relay + sudo infisical relay systemd install --type=instance --name= --host= --relay-auth-secret= + + # Start the service + sudo systemctl start infisical-relay + + # Uninstall + sudo infisical relay systemd uninstall + ``` + + + The `RELAY_AUTH_SECRET` (instance environment) and + `INFISICAL_RELAY_AUTH_SECRET` (relay environment) **must match exactly** for + authentication to work. + + + + + + Deploy your own relay server for full control. Organization relays support all authentication methods: + + ```bash + # Token auth + infisical relay start --type=org --host= --name= --token= + + # Universal auth + infisical relay start --type=org --host= --name= --auth-method=universal-auth --client-id= --client-secret= + + # Other auth methods (kubernetes, aws-iam, gcp-id-token, azure, etc.) + infisical relay start --type=org --host= --name= --auth-method= --machine-identity-id= + ``` + + **Install as daemon (Linux only):** + + ```bash + # Organization relay + sudo infisical relay systemd install --token= --name= --host= --type=org + + # Start the service + sudo systemctl start infisical-relay + + # Uninstall + sudo infisical relay systemd uninstall + ``` + + + + +## Network Configuration + +### Relay Server Network Requirements + +The relay server must accept inbound connections and make outbound connections to function properly: + +#### Inbound Connections (Required) + +The relay server must accept the following inbound connections: + +| Protocol | Source | Port | Purpose | +| -------- | ------------------ | ---- | -------------------------------- | +| TCP | Gateways | 2222 | SSH reverse tunnel establishment | +| TCP | Infisical Platform | 8443 | Platform-to-relay communication | + +#### Outbound Connections (Required) + +The relay server requires outbound connectivity to: + +| Protocol | Destination | Port | Purpose | +| -------- | ------------------------------------ | ---- | ------------------------------------------ | +| TCP | app.infisical.com / eu.infisical.com | 443 | API communication and certificate requests | + +## Firewall Configuration + +### Relay Firewall Rules + +Configure your firewall to allow: + +1. **SSH on port 2222** - For gateway connections + + ```bash + # Example iptables rule + iptables -A INPUT -p tcp --dport 2222 -j ACCEPT + ``` + +2. **TCP with TLS on port 8443** - For platform connections + + ```bash + # Example iptables rule + iptables -A INPUT -p tcp --dport 8443 -j ACCEPT + ``` + +3. **HTTPS to Infisical API** - For certificate requests and API communication + ```bash + # Example iptables rule + iptables -A OUTPUT -p tcp --dport 443 -d app.infisical.com -j ACCEPT + ``` + +## Cloud Provider Configuration + +### AWS EC2 + +Configure security groups: + +```json +{ + "SecurityGroupRules": [ + { + "IpProtocol": "tcp", + "FromPort": 2222, + "ToPort": 2222, + "CidrIpv4": "0.0.0.0/0", + "Description": "SSH for gateway connections" + }, + { + "IpProtocol": "tcp", + "FromPort": 8443, + "ToPort": 8443, + "CidrIpv4": "0.0.0.0/0", + "Description": "TCP with TLS for platform connections" + } + ] +} +``` + +### Google Cloud Platform + +Configure firewall rules: + +```bash +# Allow SSH from gateways +gcloud compute firewall-rules create allow-gateway-ssh \ + --allow tcp:2222 \ + --source-ranges 0.0.0.0/0 \ + --description "Allow SSH from gateways" + +# Allow TCP with TLS from platform +gcloud compute firewall-rules create allow-platform-tls \ + --allow tcp:8443 \ + --source-ranges 0.0.0.0/0 \ + --description "Allow TCP with TLS from platform" +``` + +### Azure + +Configure Network Security Groups: + +```json +{ + "securityRules": [ + { + "name": "AllowGatewaySSH", + "properties": { + "protocol": "Tcp", + "sourcePortRange": "*", + "destinationPortRange": "2222", + "sourceAddressPrefix": "*", + "destinationAddressPrefix": "*", + "access": "Allow", + "priority": 100, + "direction": "Inbound" + } + }, + { + "name": "AllowPlatformTLS", + "properties": { + "protocol": "Tcp", + "sourcePortRange": "*", + "destinationPortRange": "8443", + "sourceAddressPrefix": "*", + "destinationAddressPrefix": "*", + "access": "Allow", + "priority": 110, + "direction": "Inbound" + } + } + ] +} +``` + +## Protocol Details + +### SSH over TCP + +The gateway uses SSH reverse tunnels for primary communication: + +- **Port 2222**: SSH connection from gateways to relay servers +- **Built-in features**: Automatic reconnection, certificate-based authentication, encrypted tunneling +- **Encryption**: SSH with certificate-based authentication and key exchange + +### 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 + +## Performance Considerations + +### Network Optimization + +- **Deploy close to gateways** - Reduce latency by placing relay servers geographically close to your gateways +- **Use high-bandwidth connections** - Ensure adequate bandwidth for encrypted traffic +- **Monitor network performance** - Track latency and throughput metrics +- **Consider multiple relays** - Deploy multiple relay servers for redundancy and load distribution + +## Best Practices + +### Relay Security + +- **Secure secret management** - For instance relays, ensure `RELAY_AUTH_SECRET` and `INFISICAL_RELAY_AUTH_SECRET` are stored securely +- **Network isolation** - Use security groups and network ACLs to restrict relay access +- **Regular updates** - Keep relay servers updated and patched +- **Monitor traffic** - Watch for unusual connection patterns or traffic volume + +### Performance & Reliability + +- **Deploy relays strategically** - Deploy close to gateways to minimize latency +- **Use multiple instances** - Deploy multiple relay servers for redundancy +- **Monitor resource usage** - Track CPU, memory, and network usage for relays +- **Health monitoring** - Set up monitoring for relay connection status +- **Automatic restart** - Use systemd to automatically restart failed services + +## Troubleshooting + +### Common Issues + +**Relay not accessible from gateways:** + +- Check firewall rules allow inbound SSH on port 2222 +- Verify public IP is correctly configured +- Test connectivity: `telnet 2222` + +**Platform cannot connect to relay:** + +- Check firewall rules allow inbound TCP with TLS on port 8443 +- Verify SSL certificate is properly configured +- Test connectivity: `openssl s_client -connect :8443` + +**Authentication failures:** + +- For instance relays: Verify `RELAY_AUTH_SECRET` matches `INFISICAL_RELAY_AUTH_SECRET` +- For organization relays: Check machine identity credentials and permissions +- Ensure authentication method is properly configured + +### Logs + +Check relay logs for detailed error information: + +```bash +# systemd service +sudo journalctl -u infisical-relay -f + +# Local installation +# Logs appear in the terminal where you started the relay +``` + +### Network Testing + +Test relay connectivity: + +```bash +# Test SSH port from gateway +nc -zv 2222 + +# Test TCP with TLS port from platform +openssl s_client -connect :8443 + +# Test outbound API access +curl -I https://app.infisical.com +``` + +## 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 +- **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. + + + + +Choose based on your specific requirements: + +**Use Instance Relays when:** + +- Getting started quickly is a priority +- You want minimal operational overhead +- Shared infrastructure is acceptable +- You don't have specific latency requirements + +**Use Organization Relays when:** + +- You need dedicated relay resources +- Lower latency is critical (deploy closer to gateways) +- You have compliance requirements for data routing +- You want full control over relay infrastructure +- You need custom network policies + +Most users should start with Instance Relays and migrate to Organization Relays only if they have specific requirements that aren't met by the managed infrastructure. + + + + +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 +- **Multiple relays**: Deploy multiple relay servers for redundancy and high availability +- **Monitoring**: Set up monitoring to detect relay outages quickly +- **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. + + From 7aaafb19e946c608afadfb719c7585fd14344229 Mon Sep 17 00:00:00 2001 From: Maidul Islam Date: Thu, 18 Sep 2025 01:36:59 -0400 Subject: [PATCH 03/12] revamp gateway overview docs --- .../platform/gateways/overview.mdx | 114 ++++++++---------- 1 file changed, 47 insertions(+), 67 deletions(-) diff --git a/docs/documentation/platform/gateways/overview.mdx b/docs/documentation/platform/gateways/overview.mdx index 266f2ad16..c04f2f7d3 100644 --- a/docs/documentation/platform/gateways/overview.mdx +++ b/docs/documentation/platform/gateways/overview.mdx @@ -6,7 +6,9 @@ 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. +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 @@ -15,84 +17,62 @@ The Infisical Gateway provides secure access to private resources within your ne license. -## What are Gateways and Relays? +## Core Components -### Gateway +The Gateway system consists of two primary components working together to enable secure network access: -A lightweight service deployed within your VPCs that provides secure access to private resources: + + + 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. -- **Runs inside your network** - Deployed within your VPCs, data centers, or on-premises infrastructure -- **Makes outbound connections only** - No inbound firewall rules required -- **Provides secure access** - Uses SSH reverse tunnels and certificate-based authentication -- **Handles resource connections** - Connects to your private databases, APIs, and services + 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. -### Relay Server + **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 + -Infrastructure that routes encrypted traffic between the Infisical platform and gateways: + + 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. -- **Routes encrypted traffic** - Routes traffic between the platform and gateways -- **Provides network isolation** - Enables communication without direct connections -- **Handles authentication** - Manages SSH certificate validation and routing -- **Ensures security** - Uses double encryption to protect data in transit + **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 + + **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. + + ## 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 +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 -**Key Benefits:** +## Getting Started -- **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 +Ready to set up your gateway? Follow the guides below. -## Understanding Relay Types - -Relays are the routing infrastructure that enables secure communication between Infisical and your gateways. There are two main approaches to relay deployment: - -**Managed Relays** - Use Infisical's hosted relay infrastructure in US/EU regions for quick setup with minimal operational overhead. - -**Self-Deployed Relays** - Deploy your own relay servers for regional proximity, enhanced control, and custom network policies. - -### Managed Relays (Recommended for Most Users) - -Managed relays are pre-configured relay servers hosted by Infisical that can serve multiple organizations with minimal operational overhead. - -**Infisical Cloud (US/EU Regions):** - -- Pre-configured relays in US and EU regions -- No setup or maintenance required -- Shared across all Infisical Cloud organizations -- Managed and monitored by Infisical -- Best for getting started quickly - -**Self-Hosted Instance Relays:** - -- Instance administrators can deploy shared relays for their entire instance -- All organizations on the instance can use these relays -- Reduces operational burden for individual Organizations -- Ideal for self-hosted instances wanting shared relay infrastructure - -### Self-Deployed Relays (Organization-Specific) - -Organizations can deploy and manage their own dedicated relay servers for regional proximity, network control, compliance requirements, or enhanced security. - -**Key Benefits:** - -- Deploy in any region or cloud provider for lower latency -- Custom network configurations and security policies -- Dedicated resources not shared with other organizations -- Full control over relay infrastructure -- Uses standard Infisical authentication methods - -## Next Steps - -Ready to get started? Follow these guides: - -1. **[Gateway Deployment](/documentation/platform/gateways/gateway-deployment)** - Complete gateway deployment and network configuration -2. **[Relay Deployment](/documentation/platform/gateways/relay-deployment)** - Complete relay deployment and network configuration -3. **[Security Architecture](/documentation/platform/gateways/security)** - Security model and best practices + + + 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 From d3d3fbe5c57ee1abc77e85d5664cb91a27082ea4 Mon Sep 17 00:00:00 2001 From: Maidul Islam Date: Thu, 18 Sep 2025 13:25:00 -0400 Subject: [PATCH 04/12] revamp gateway docs --- .../platform/gateways/gateway-deployment.mdx | 538 +++++++----------- 1 file changed, 216 insertions(+), 322 deletions(-) diff --git a/docs/documentation/platform/gateways/gateway-deployment.mdx b/docs/documentation/platform/gateways/gateway-deployment.mdx index f939744c3..527bb652c 100644 --- a/docs/documentation/platform/gateways/gateway-deployment.mdx +++ b/docs/documentation/platform/gateways/gateway-deployment.mdx @@ -3,328 +3,253 @@ title: "Gateway Deployment" description: "Complete guide to deploying Infisical Gateways including network configuration and firewall requirements" --- -This guide covers everything you need to deploy and configure Infisical Gateways, including prerequisites, step-by-step deployment instructions, network configuration, and troubleshooting. +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. -## Prerequisites +## Deployment Steps -Before deploying gateways, ensure you have: +To successfully deploy an Infisical Gateway for use, follow these steps in order. -1. **Machine Identity** - Configured with appropriate permissions to create and manage gateways -2. **Relay Server** - A running relay server before deploying gateways. This can be either a managed relay (like Infisical's US/EU relays) or your own self-deployed relay server (see [Relay Deployment Guide](/documentation/platform/gateways/relay-deployment)) + + + 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. -## Gateway Deployment Methods + + + 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 can use either: + - A managed relay provided by Infisical (such as the US/EU relays). If you are on a dedicated Infisical managed instance, a relay will be provisioned for you to use. + - Your own self-hosted relay server. 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. -### Linux Server Deployment (Production) + 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. -For production deployments on Linux servers, install the Gateway as a systemd service: + | 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 | - - **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 will create a completely new gateway rather than upgrading your existing one. Gateway v2 provisions new gateway instances with new gateway IDs. You'll need to update any resources that reference the old 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 -- Automatically restarts on failure -- Starts on system boot -- Manages token and domain configuration securely in `/etc/infisical/gateway.conf` - - - The systemd install command requires a Linux operating system with root/sudo - privileges. - - -### Kubernetes Cluster Deployment (Production) - -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 -``` - - - **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 will create a completely new gateway rather than upgrading your existing one. Gateway v2 provisions new gateway instances with new gateway IDs. You'll need to update any resources that reference the old gateway ID (for example: dynamic secret configs, app connections, or other gateway-bound resources) to use the new Gateway v2 gateway ID. - - - -### Development & Testing - -For development or testing environments: - -```bash -# Direct execution with token -infisical gateway start --token --relay= --name= - -# Using environment variable -export INFISICAL_TOKEN= -infisical gateway start --relay= --name= -``` - -## Authentication Methods - -The gateway supports multiple authentication methods. Choose the one that best fits your environment: - - - - Simple and secure authentication using client ID and client secret. + 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. - **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=` - - + 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. -## Environment Variables + 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 + ``` -In addition to authentication, you must set these required variables: -- `INFISICAL_RELAY_NAME` - The name of the relay server to connect to -- `INFISICAL_GATEWAY_NAME` - A unique name for this gateway instance -Optional variables: + + The systemd install command requires a Linux operating system with root/sudo + privileges. + + -- `INFISICAL_API_URL` - The Infisical API URL (defaults to `https://app.infisical.com`) + + For production deployments on Kubernetes clusters, install the Gateway using the Infisical Helm chart: -## Network Configuration + #### Install the latest Helm Chart repository -### Gateway Network Requirements + ```bash + helm repo add infisical-helm-charts 'https://dl.cloudsmith.io/public/infisical/helm-charts/helm/charts/' + helm repo update + ``` -The gateway uses SSH reverse tunnels to establish secure connections with end-to-end encryption: + #### Create a Kubernetes Secret -1. **Gateway** connects outbound to **Relay Servers** using SSH over TCP -2. **Infisical platform** establishes mTLS connections with gateways via the relay servers 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 + The gateway supports all identity authentication methods through environment variables: -### Outbound Connections (Required) + ```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 gateway requires the following outbound connectivity: + #### Install the Gateway -| 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 | + ```bash + helm install infisical-gateway infisical-helm-charts/infisical-gateway + ``` + -### Relay Server Connectivity + + For development or testing environments: -Your gateway needs to connect to a relay server on port 2222. The specific relay server depends on your setup: + ```bash + infisical gateway start --token --relay= --name= + ``` + + + -**Managed Relays (Infisical Cloud):** + + After deployment, verify your gateway is working: -- Use Infisical's pre-configured relay servers in US/EU regions -- Static IP addresses available for firewall whitelisting -- Allow outbound TCP connections to the relay server IP on port 2222 + 1. **Check logs** for "Gateway started successfully" message indicating the gateway is running and connected to the relay -**Self-Deployed or Instance Relays:** + 2. **Verify registration** in the Infisical by visiting the Gateways section of your organization. The new gateway should appear with a recent heartbeat timestamp. -- Connect to your own relay server or relay servers deployed by your instance administrator -- Allow outbound TCP connections to your relay server IP/hostname on port 2222 -- Example: If your relay is at `203.0.113.100`, allow TCP to `203.0.113.100:2222` -- For instance relays, contact your admin for the specific relay server addresses + 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. + + -## Firewall Configuration -### Gateway Firewall Rules -Since gateways only make outbound connections, 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 - -## Verification - -After deployment, verify your gateway is working: - -1. **Check logs** for "Gateway started successfully" message -2. **Verify registration** in the Infisical dashboard under Organization Access Control > Gateways -3. **Test connectivity** by creating a dynamic secret or app connection - -## Best Practices - -### Gateway Security - -- **One identity per gateway** - Create a unique machine identity for each gateway -- **Minimal permissions** - Assign only the permissions each gateway actually needs -- **Rotate credentials** - Set up regular credential rotation -- **Monitor authentication** - Watch for unusual authentication activity - -### Performance & Reliability - -- **Deploy close to resources** - Place gateways as close as possible to your private resources -- **Use multiple instances** - Deploy multiple gateways for redundancy -- **Monitor resource usage** - Track CPU, memory, and network usage for gateways -- **Health monitoring** - Set up monitoring for gateway connection status -- **Automatic restart** - Use systemd or Kubernetes to automatically restart failed services - -## Troubleshooting - -### Common Issues - -**Gateway fails to start:** - -- Verify machine identity has correct permissions -- Check network connectivity to relay server -- Ensure all required environment variables are set - -**Cannot connect to relay:** - -- Verify relay server is running and accessible -- Check firewall rules allow outbound connections on port 2222 -- Confirm relay name matches exactly - -**Authentication failures:** - -- Verify machine identity credentials are correct -- Check token expiration and renewal -- Ensure authentication method is properly configured - -### Logs - -Check gateway logs for detailed error information: - -```bash -# systemd service -sudo journalctl -u infisical-gateway -f - -# Kubernetes -kubectl logs deployment/infisical-gateway - -# Local installation -# Logs appear in the terminal where you started the gateway -``` - -### Network Testing - -Test relay connectivity from gateway: - -```bash -# Test SSH port to relay -nc -zv 2222 - -# Test outbound API access -curl -I https://app.infisical.com -``` ## 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: @@ -338,34 +263,3 @@ The gateway is designed to handle network interruptions gracefully: No manual intervention is typically required during network interruptions. - - -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. - - - - -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 - - From 5ba1993b9c78ad2138b6c561f9f4d53c89b5cc2c Mon Sep 17 00:00:00 2001 From: Maidul Islam Date: Thu, 18 Sep 2025 13:40:14 -0400 Subject: [PATCH 05/12] update when you should deploy your own relay --- docs/documentation/platform/gateways/gateway-deployment.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/documentation/platform/gateways/gateway-deployment.mdx b/docs/documentation/platform/gateways/gateway-deployment.mdx index 527bb652c..0d44e214f 100644 --- a/docs/documentation/platform/gateways/gateway-deployment.mdx +++ b/docs/documentation/platform/gateways/gateway-deployment.mdx @@ -93,9 +93,9 @@ To successfully deploy an Infisical Gateway for use, follow these steps in order - Ensure a relay server is running and accessible before you deploy any gateways. You can use either: - - A managed relay provided by Infisical (such as the US/EU relays). If you are on a dedicated Infisical managed instance, a relay will be provisioned for you to use. - - Your own self-hosted relay server. For setup instructions, see the Relay Deployment Guide. + 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, dedicated, or non-US/EU Infisical Cloud instances, you must deploy your own relay server. You can also choose to deploy your own relay server with Infisical Cloud if you require geographic proximity 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. From ff442aaa28758d5a5c9d24220877875e924f2943 Mon Sep 17 00:00:00 2001 From: Maidul Islam Date: Fri, 19 Sep 2025 02:04:44 -0400 Subject: [PATCH 06/12] leave commits and update relay docs --- .../platform/gateways/relay-deployment.mdx | 230 ++---------------- 1 file changed, 19 insertions(+), 211 deletions(-) diff --git a/docs/documentation/platform/gateways/relay-deployment.mdx b/docs/documentation/platform/gateways/relay-deployment.mdx index c90576d46..215a663f9 100644 --- a/docs/documentation/platform/gateways/relay-deployment.mdx +++ b/docs/documentation/platform/gateways/relay-deployment.mdx @@ -1,151 +1,39 @@ --- title: "Relay Deployment" -description: "Complete guide to deploying Infisical Relay Servers including network configuration and firewall requirements" +description: "How to deploy Infisical Relay Servers" --- -This guide covers everything you need to deploy and configure Infisical Relay Servers, including prerequisites, step-by-step deployment instructions, network configuration, and troubleshooting. +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. -## Prerequisites +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. -Before deploying relays, ensure you have: +## Do You Need to Deploy a Relay? -1. **Server Infrastructure** - A server or cloud instance to host the relay -2. **Network Connectivity** - Ability to accept inbound connections on ports 2222 and 8443, plus outbound HTTPS access to Infisical API -3. **Machine Identity** - Only required for organization relays; configured with appropriate permissions to create and manage relays +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: - - **Instance relays** don't require machine identities - they use a shared - secret configured by the instance administrator. - +- Are self-hosting Infisical +- Have a dedicated Infisical instance (managed by Infisical) +- Require dedicated relays for your organization (for compliance, custom network policies, or regional proximity) +- Need full control over relay infrastructure and traffic routing -## Understanding Relay Types +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. -Relays are the routing infrastructure that enables secure communication between Infisical and your gateways. There are two main approaches to relay deployment: -**Managed Relays** - Use Infisical's hosted relay infrastructure in US/EU regions for quick setup with minimal operational overhead. -**Self-Deployed Relays** - Deploy your own relay servers for regional proximity, enhanced control, and custom network policies. -### Managed Relays (Recommended for Most Users) +## Deploying a Relay -Managed relays are pre-configured relay servers hosted by Infisical that can serve multiple organizations with minimal operational overhead. +Deploying a relay allows Infisical to securely connect to your private network resources. This method applies to all Infisical environments—Cloud (US/EU), Dedicated, and Self-Hosted. You have full control over the relay infrastructure and can meet compliance or custom network requirements as needed. -**Infisical Cloud (US/EU Regions):** -- Pre-configured relays in US and EU regions -- No setup or maintenance required -- Shared across all Infisical Cloud organizations -- Managed and monitored by Infisical -- Best for getting started quickly + + +all the steps should go here + -**Self-Hosted Instance Relays:** - -- Instance administrators can deploy shared relays for their entire instance -- All organizations on the instance can use these relays -- Reduces operational burden for individual Organizations -- Ideal for self-hosted instances wanting shared relay infrastructure - -### Self-Deployed Relays (Organization-Specific) - -Organizations can deploy and manage their own dedicated relay servers for regional proximity, network control, compliance requirements, or enhanced security. - -**Key Benefits:** - -- Deploy in any region or cloud provider for lower latency -- Custom network configurations and security policies -- Dedicated resources not shared with other organizations -- Full control over relay infrastructure -- Uses standard Infisical authentication methods - -## Relay Deployment Methods - -If you've decided to deploy your own relay servers, choose the deployment type that best fits your needs: - -- **Instance Relays** - Deploy shared relays for your entire self-hosted Infisical instance. All organizations on the instance can use these relays without deploying their own. - -- **Organization Relays** - Deploy and manage your own dedicated relay servers. Choose this for lower latency, custom network policies, compliance requirements, or when you need full control over the relay infrastructure. - - - **Note:** If you're using Infisical Cloud, you likely don't need to deploy - relays at all - you can use the managed US/EU relays. This guide is for users - who need to deploy their own relay infrastructure. - - - - - Instance relays require **two-step configuration** with matching secrets: - - **Step 1: Instance Admin Configuration** - - The Infisical instance administrator must first set the relay auth secret in the instance environment: - - ```bash - # In the Infisical instance environment variables - RELAY_AUTH_SECRET= - ``` - - **Step 2: Relay Deployment** - - Deploy the relay using the **same secret value**: - - ```bash - # Set the matching secret for relay deployment - export INFISICAL_RELAY_AUTH_SECRET= - - # Start the instance relay - infisical relay start --type=instance --host= --name= - ``` - - **Install as daemon (Linux only):** - - ```bash - # Instance relay - sudo infisical relay systemd install --type=instance --name= --host= --relay-auth-secret= - - # Start the service - sudo systemctl start infisical-relay - - # Uninstall - sudo infisical relay systemd uninstall - ``` - - - The `RELAY_AUTH_SECRET` (instance environment) and - `INFISICAL_RELAY_AUTH_SECRET` (relay environment) **must match exactly** for - authentication to work. - - - - - - Deploy your own relay server for full control. Organization relays support all authentication methods: - - ```bash - # Token auth - infisical relay start --type=org --host= --name= --token= - - # Universal auth - infisical relay start --type=org --host= --name= --auth-method=universal-auth --client-id= --client-secret= - - # Other auth methods (kubernetes, aws-iam, gcp-id-token, azure, etc.) - infisical relay start --type=org --host= --name= --auth-method= --machine-identity-id= - ``` - - **Install as daemon (Linux only):** - - ```bash - # Organization relay - sudo infisical relay systemd install --token= --name= --host= --type=org - - # Start the service - sudo systemctl start infisical-relay - - # Uninstall - sudo infisical relay systemd uninstall - ``` - - - + ## Network Configuration @@ -196,87 +84,7 @@ Configure your firewall to allow: iptables -A OUTPUT -p tcp --dport 443 -d app.infisical.com -j ACCEPT ``` -## Cloud Provider Configuration -### AWS EC2 - -Configure security groups: - -```json -{ - "SecurityGroupRules": [ - { - "IpProtocol": "tcp", - "FromPort": 2222, - "ToPort": 2222, - "CidrIpv4": "0.0.0.0/0", - "Description": "SSH for gateway connections" - }, - { - "IpProtocol": "tcp", - "FromPort": 8443, - "ToPort": 8443, - "CidrIpv4": "0.0.0.0/0", - "Description": "TCP with TLS for platform connections" - } - ] -} -``` - -### Google Cloud Platform - -Configure firewall rules: - -```bash -# Allow SSH from gateways -gcloud compute firewall-rules create allow-gateway-ssh \ - --allow tcp:2222 \ - --source-ranges 0.0.0.0/0 \ - --description "Allow SSH from gateways" - -# Allow TCP with TLS from platform -gcloud compute firewall-rules create allow-platform-tls \ - --allow tcp:8443 \ - --source-ranges 0.0.0.0/0 \ - --description "Allow TCP with TLS from platform" -``` - -### Azure - -Configure Network Security Groups: - -```json -{ - "securityRules": [ - { - "name": "AllowGatewaySSH", - "properties": { - "protocol": "Tcp", - "sourcePortRange": "*", - "destinationPortRange": "2222", - "sourceAddressPrefix": "*", - "destinationAddressPrefix": "*", - "access": "Allow", - "priority": 100, - "direction": "Inbound" - } - }, - { - "name": "AllowPlatformTLS", - "properties": { - "protocol": "Tcp", - "sourcePortRange": "*", - "destinationPortRange": "8443", - "sourceAddressPrefix": "*", - "destinationAddressPrefix": "*", - "access": "Allow", - "priority": 110, - "direction": "Inbound" - } - } - ] -} -``` ## Protocol Details From 3ec8b7da177049f65a4986201638b42e40d66379 Mon Sep 17 00:00:00 2001 From: Sheen Capadngan Date: Fri, 19 Sep 2025 19:04:15 +0800 Subject: [PATCH 07/12] misc: updated relay deploymetn dc --- .../platform/gateways/relay-deployment.mdx | 287 +++++++----------- 1 file changed, 115 insertions(+), 172 deletions(-) diff --git a/docs/documentation/platform/gateways/relay-deployment.mdx b/docs/documentation/platform/gateways/relay-deployment.mdx index 215a663f9..f256a197a 100644 --- a/docs/documentation/platform/gateways/relay-deployment.mdx +++ b/docs/documentation/platform/gateways/relay-deployment.mdx @@ -3,8 +3,8 @@ 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. +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. @@ -20,166 +20,99 @@ Not all users need to deploy their own relay servers. Infisical provides managed 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 - - -## Deploying a Relay - -Deploying a relay allows Infisical to securely connect to your private network resources. This method applies to all Infisical environments—Cloud (US/EU), Dedicated, and Self-Hosted. You have full control over the relay infrastructure and can meet compliance or custom network requirements as needed. - +To successfully deploy an Infisical Relay for use, follow these steps in order. - -all the steps should go here - + + Before deploying your relay server, ensure you have: + + - A server with a static IP address or DNS + - Administrative access to configure firewall rules + - Access to create machine identities in your Infisical organization + - The Infisical CLI installed on your deployment environment + + + + + Create a machine identity with the appropriate permissions for your relay: + + 1. **Create a machine identity** in your Infisical organization with permissions to create and manage relays. + + 2. **Choose an authentication method** from the supported [machine identity auth methods](/documentation/platform/identities/machine-identities) + + 3. **Configure environment variables** corresponding to your chosen authentication method when deploying the relay The relay will use this machine identity to authenticate with Infisical and register itself within your organization. + + + + + Make sure the Infisical CLI is installed 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. + + + + + Ensure your network and firewall settings allow the server to accept inbound connections and make outbound connections: + + **Inbound Connections:** + | 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:** + | 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). + + ```bash + sudo infisical relay systemd install \ + --token \ + --name \ + --domain \ + --host + + # Start the relay service + sudo systemctl start infisical-relay + sudo systemctl enable infisical-relay + ``` + + + The systemd install command requires a Linux operating system with root/sudo privileges. + + + + + 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. + + + + -## Network Configuration - -### Relay Server Network Requirements - -The relay server must accept inbound connections and make outbound connections to function properly: - -#### Inbound Connections (Required) - -The relay server must accept the following inbound connections: - -| Protocol | Source | Port | Purpose | -| -------- | ------------------ | ---- | -------------------------------- | -| TCP | Gateways | 2222 | SSH reverse tunnel establishment | -| TCP | Infisical Platform | 8443 | Platform-to-relay communication | - -#### Outbound Connections (Required) - -The relay server requires outbound connectivity to: - -| Protocol | Destination | Port | Purpose | -| -------- | ------------------------------------ | ---- | ------------------------------------------ | -| TCP | app.infisical.com / eu.infisical.com | 443 | API communication and certificate requests | - -## Firewall Configuration - -### Relay Firewall Rules - -Configure your firewall to allow: - -1. **SSH on port 2222** - For gateway connections - - ```bash - # Example iptables rule - iptables -A INPUT -p tcp --dport 2222 -j ACCEPT - ``` - -2. **TCP with TLS on port 8443** - For platform connections - - ```bash - # Example iptables rule - iptables -A INPUT -p tcp --dport 8443 -j ACCEPT - ``` - -3. **HTTPS to Infisical API** - For certificate requests and API communication - ```bash - # Example iptables rule - iptables -A OUTPUT -p tcp --dport 443 -d app.infisical.com -j ACCEPT - ``` - - - -## Protocol Details - -### SSH over TCP - -The gateway uses SSH reverse tunnels for primary communication: - -- **Port 2222**: SSH connection from gateways to relay servers -- **Built-in features**: Automatic reconnection, certificate-based authentication, encrypted tunneling -- **Encryption**: SSH with certificate-based authentication and key exchange - -### 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 - -## Performance Considerations - -### Network Optimization - -- **Deploy close to gateways** - Reduce latency by placing relay servers geographically close to your gateways -- **Use high-bandwidth connections** - Ensure adequate bandwidth for encrypted traffic -- **Monitor network performance** - Track latency and throughput metrics -- **Consider multiple relays** - Deploy multiple relay servers for redundancy and load distribution - -## Best Practices - -### Relay Security - -- **Secure secret management** - For instance relays, ensure `RELAY_AUTH_SECRET` and `INFISICAL_RELAY_AUTH_SECRET` are stored securely -- **Network isolation** - Use security groups and network ACLs to restrict relay access -- **Regular updates** - Keep relay servers updated and patched -- **Monitor traffic** - Watch for unusual connection patterns or traffic volume - -### Performance & Reliability - -- **Deploy relays strategically** - Deploy close to gateways to minimize latency -- **Use multiple instances** - Deploy multiple relay servers for redundancy -- **Monitor resource usage** - Track CPU, memory, and network usage for relays -- **Health monitoring** - Set up monitoring for relay connection status -- **Automatic restart** - Use systemd to automatically restart failed services - -## Troubleshooting - -### Common Issues - -**Relay not accessible from gateways:** - -- Check firewall rules allow inbound SSH on port 2222 -- Verify public IP is correctly configured -- Test connectivity: `telnet 2222` - -**Platform cannot connect to relay:** - -- Check firewall rules allow inbound TCP with TLS on port 8443 -- Verify SSL certificate is properly configured -- Test connectivity: `openssl s_client -connect :8443` - -**Authentication failures:** - -- For instance relays: Verify `RELAY_AUTH_SECRET` matches `INFISICAL_RELAY_AUTH_SECRET` -- For organization relays: Check machine identity credentials and permissions -- Ensure authentication method is properly configured - -### Logs - -Check relay logs for detailed error information: - -```bash -# systemd service -sudo journalctl -u infisical-relay -f - -# Local installation -# Logs appear in the terminal where you started the relay -``` - -### Network Testing - -Test relay connectivity: - -```bash -# Test SSH port from gateway -nc -zv 2222 - -# Test TCP with TLS port from platform -openssl s_client -connect :8443 - -# Test outbound API access -curl -I https://app.infisical.com -``` - ## Frequently Asked Questions @@ -189,32 +122,42 @@ No, relay servers cannot decrypt any traffic passing through them due to end-to- - **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. - -Choose based on your specific requirements: + +Deploying your own relay provides several advantages: -**Use Instance Relays when:** +- **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 +- **High availability**: Deploy multiple relays for redundancy and load distribution -- Getting started quickly is a priority -- You want minimal operational overhead -- Shared infrastructure is acceptable -- You don't have specific latency requirements +Organization-deployed relays give you complete control over your secure communication infrastructure. -**Use Organization Relays when:** + -- You need dedicated relay resources -- Lower latency is critical (deploy closer to gateways) -- You have compliance requirements for data routing -- You want full control over relay infrastructure -- You need custom network policies + +For detailed troubleshooting: -Most users should start with Instance Relays and migrate to Organization Relays only if they have specific requirements that aren't met by the managed infrastructure. +**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 +curl -I https://app.infisical.com + +# Test TCP with TLS port from platform +openssl s_client -connect :8443 +``` From 2ce7629dfe1e78ed95373eaf25687bcfb42f3d7d Mon Sep 17 00:00:00 2001 From: Sheen Capadngan Date: Fri, 19 Sep 2025 19:11:43 +0800 Subject: [PATCH 08/12] misc: updated CLI relay docs to remove mentions of instance type --- docs/cli/commands/relay.mdx | 136 ++++++++---------------------------- 1 file changed, 31 insertions(+), 105 deletions(-) diff --git a/docs/cli/commands/relay.mdx b/docs/cli/commands/relay.mdx index 7530ee99d..a81eda5d8 100644 --- a/docs/cli/commands/relay.mdx +++ b/docs/cli/commands/relay.mdx @@ -6,13 +6,13 @@ 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 --type= --host= --name= --token= + sudo infisical relay systemd install --host= --name= --token= # Uninstall systemd service sudo infisical relay systemd uninstall @@ -22,48 +22,30 @@ description: "Relay-related commands for Infisical" ## 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) +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. The relay system uses SSH reverse tunnels over TCP, eliminating firewall complexity and providing excellent performance for enterprise environments. ## 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 ``` @@ -73,30 +55,23 @@ infisical relay start --type= --host= --name= --auth-method= ### 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 -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. @@ -117,7 +92,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= ``` @@ -141,7 +116,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= ``` @@ -162,7 +137,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= ``` @@ -183,7 +158,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= ``` @@ -205,7 +180,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= ``` @@ -224,7 +199,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= ``` @@ -246,7 +221,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= ``` @@ -270,7 +245,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= ``` @@ -286,32 +261,12 @@ 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 - -**When to use Instance Relays (`--type=instance`):** - -- 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 - -**When to use Organization Relays (`--type=org`):** - -- 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 - @@ -331,36 +286,20 @@ infisical relay systemd Install and enable systemd service for the relay. Must be run with sudo on Linux systems. ```bash -sudo infisical relay systemd install --type= --host= --name= [flags] +sudo infisical relay systemd install --host= --name= --token= [flags] ``` #### 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. Requires `--relay-auth-secret` flag or `INFISICAL_RELAY_AUTH_SECRET` environment variable. - - **`org`**: Dedicated relay server that individual organizations deploy and manage in their own infrastructure. Requires `--token` flag. - -```bash -# Organization relay -sudo infisical relay systemd install --type=org --host=192.168.1.100 --name=my-org-relay --token= - -# Instance relay -sudo infisical relay systemd install --type=instance --host=10.0.1.50 --name=shared-relay --relay-auth-secret= -``` - - - 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 --type=org --name=my-relay --token= +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 --type=org --name=my-relay --token= +sudo infisical relay systemd install --host=relay.example.com --name=my-relay --token= ``` @@ -370,17 +309,17 @@ sudo infisical relay systemd install --host=relay.example.com --type=org --name= ```bash # Example -sudo infisical relay systemd install --name=my-relay --type=org --host=192.168.1.100 --token= +sudo infisical relay systemd install --name=my-relay --host=192.168.1.100 --token= ``` - Connect with Infisical using machine identity access token. Required for organization relays (`--type=org`). + Connect with Infisical using machine identity access token. ```bash # Example -sudo infisical relay systemd install --token= --type=org --host= --name= +sudo infisical relay systemd install --token= --host= --name= ``` @@ -390,17 +329,7 @@ sudo infisical relay systemd install --token= --type=org ```bash # Example -sudo infisical relay systemd install --domain=http://localhost:8080 --token= --type=org --host= --name= -``` - - - - - Relay auth secret. Required for instance relays (`--type=instance`) if the `INFISICAL_RELAY_AUTH_SECRET` environment variable is not set. - -```bash -# Example -sudo infisical relay systemd install --relay-auth-secret= --type=instance --host= --name= +sudo infisical relay systemd install --domain=http://localhost:8080 --token= --host= --name= ``` @@ -408,14 +337,11 @@ sudo infisical relay systemd install --relay-auth-secret= --type=instanc #### Examples ```bash -# Install organization relay with token authentication -sudo infisical relay systemd install --type=org --host=192.168.1.100 --name=my-org-relay --token= - -# Install instance relay with auth secret -sudo infisical relay systemd install --type=instance --host=10.0.1.50 --name=shared-relay --relay-auth-secret= +# 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= --type=org --host= --name= +sudo infisical relay systemd install --domain=http://localhost:8080 --token= --host= --name= ``` #### Post-installation From 262f4fa2d3d1b4874f335fd84318031c235e9d90 Mon Sep 17 00:00:00 2001 From: Sheen Capadngan Date: Fri, 19 Sep 2025 19:16:00 +0800 Subject: [PATCH 09/12] misc: removed unnecessary section in security architecture --- .../platform/gateways/security.mdx | 71 ------------------- 1 file changed, 71 deletions(-) diff --git a/docs/documentation/platform/gateways/security.mdx b/docs/documentation/platform/gateways/security.mdx index db2c25f40..dc70aa36f 100644 --- a/docs/documentation/platform/gateways/security.mdx +++ b/docs/documentation/platform/gateways/security.mdx @@ -131,74 +131,3 @@ The architecture provides tenant isolation through multiple certificate authorit - 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 - -## Security Best Practices - -### Gateway Security - -- **One identity per gateway** - Create a unique machine identity for each gateway -- **Minimal permissions** - Assign only the permissions each gateway actually needs -- **Rotate credentials** - Set up regular credential rotation (quarterly recommended) -- **Monitor authentication** - Watch for unusual authentication activity -- **Deploy close to resources** - Place gateways as close as possible to your private resources -- **Use multiple gateways** - Deploy multiple gateways for redundancy and load distribution - -### Relay Security - -- **Deploy close to gateways** - Minimize latency between gateways and relays -- **Use multiple regions** - Deploy relays in multiple regions for redundancy -- **Monitor performance** - Track connection counts and throughput -- **Regular updates** - Keep relay servers updated and patched -- **Network isolation** - Use security groups and network ACLs to restrict access -- **Monitor network traffic** - Watch for unusual patterns - -### Network Security - -- **Gateway outbound only** - Gateways only need outbound connections (port 2222 to relays, port 443 to Infisical API) -- **Relay inbound** - Relays need inbound SSH (2222) and TCP with TLS (8443) -- **No inbound for gateways** - Never open inbound ports for gateways -- **Use security groups** in cloud environments to restrict access -- **Implement network ACLs** to limit traffic to specific IP ranges -- **Monitor network traffic** for unusual patterns -- **Regular security updates** for the relay server - -## Compliance Considerations - -### Data Sovereignty - -- **Customer-deployed relays** - Deploy relays in your preferred geographic region -- **Air-gapped environments** - Use self-hosted relays for completely isolated deployments -- **Custom network policies** - Implement organization-specific security requirements - -### Security Controls - -- **Certificate-based authentication** - No shared secrets, uses SSH certificates -- **End-to-end encryption** - All traffic is encrypted in transit -- **Tenant isolation** - Each organization's traffic is completely isolated -- **No data storage** - Relay servers only route traffic, never store data -- **Automatic reconnection** - Handles network interruptions gracefully - -## Troubleshooting Security Issues - -### Common Security Issues - -**Authentication failures:** - -- Verify machine identity credentials are correct -- Check token expiration and renewal -- Ensure authentication method is properly configured - -**Network security issues:** - -- Verify firewall rules allow required connections -- Check for network ACLs blocking traffic -- Monitor for unusual network patterns - -### Security Monitoring - -**Key metrics to monitor:** - -- Gateway connection status and health -- Authentication success/failure rates -- Network connectivity and latency -- Unusual traffic patterns or access attempts From 040fa8c3f96299ba6b910ac808a0a9fd295c0ab4 Mon Sep 17 00:00:00 2001 From: Maidul Islam Date: Fri, 19 Sep 2025 09:39:30 -0400 Subject: [PATCH 10/12] improve gaps in relay docs --- .../platform/gateways/gateway-deployment.mdx | 2 +- .../platform/gateways/relay-deployment.mdx | 138 +++++++++++++----- 2 files changed, 104 insertions(+), 36 deletions(-) diff --git a/docs/documentation/platform/gateways/gateway-deployment.mdx b/docs/documentation/platform/gateways/gateway-deployment.mdx index 0d44e214f..40b98965a 100644 --- a/docs/documentation/platform/gateways/gateway-deployment.mdx +++ b/docs/documentation/platform/gateways/gateway-deployment.mdx @@ -95,7 +95,7 @@ To successfully deploy an Infisical Gateway for use, follow these steps in order 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, dedicated, or non-US/EU Infisical Cloud instances, you must deploy your own relay server. You can also choose to deploy your own relay server with Infisical Cloud if you require geographic proximity for lower latency or to reduce network congestion. For setup instructions, see the Relay Deployment Guide. + - **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. diff --git a/docs/documentation/platform/gateways/relay-deployment.mdx b/docs/documentation/platform/gateways/relay-deployment.mdx index f256a197a..adf5fdb9d 100644 --- a/docs/documentation/platform/gateways/relay-deployment.mdx +++ b/docs/documentation/platform/gateways/relay-deployment.mdx @@ -14,8 +14,8 @@ Before diving in, it's important to determine whether you actually need to deplo 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 Infisical instance (managed by Infisical) -- Require dedicated relays for your organization (for compliance, custom network policies, or regional proximity) +- 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. @@ -25,44 +25,107 @@ If you are using Infisical Cloud and do not have specific requirements, you can To successfully deploy an Infisical Relay for use, follow these steps in order. - - Before deploying your relay server, ensure you have: - - - A server with a static IP address or DNS - - Administrative access to configure firewall rules - - Access to create machine identities in your Infisical organization - - The Infisical CLI installed on your deployment environment - - - - Create a machine identity with the appropriate permissions for your relay: - - 1. **Create a machine identity** in your Infisical organization with permissions to create and manage relays. + 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. - 2. **Choose an authentication method** from the supported [machine identity auth methods](/documentation/platform/identities/machine-identities) - - 3. **Configure environment variables** corresponding to your chosen authentication method when deploying the relay The relay will use this machine identity to authenticate with Infisical and register itself within your organization. - + + + 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=` + + - Make sure the Infisical CLI is installed on the server where you plan to deploy the relay. The CLI is required for relay installation and management. + 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. + 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:** + **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:** + **Outbound Connections Rules:** | Protocol | Destination | Port | Purpose | | -------- | ------------------------------------ | ---- | ------------------------------------------ | | TCP | Infisical instance host (US/EU, other) | 443 | API communication and certificate requests | @@ -75,26 +138,32 @@ To successfully deploy an Infisical Relay for use, follow these steps in order. 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). + 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 + --host # Start the relay service sudo systemctl start infisical-relay sudo systemctl enable infisical-relay ``` - - - The systemd install command requires a Linux operating system with root/sudo privileges. - - + For non-Linux systems or when you need more control over the relay process: ```bash @@ -106,6 +175,7 @@ To successfully deploy an Infisical Relay for use, follow these steps in order. ``` 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. @@ -134,7 +204,7 @@ Deploying your own relay provides several advantages: - **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 +- **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. @@ -152,22 +222,20 @@ For detailed troubleshooting: **Test network connectivity:** ```bash -# Test outbound API access from relay +# 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 +- **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 -- **Monitoring**: Set up monitoring to detect relay outages quickly - **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. From 3b718fa2056005f6f8efa3f6d5d364c1760c449c Mon Sep 17 00:00:00 2001 From: Maidul Islam Date: Fri, 19 Sep 2025 09:47:55 -0400 Subject: [PATCH 11/12] edits to cli commands - gateway/relay --- docs/cli/commands/gateway.mdx | 28 ++++++++++++++-------------- docs/cli/commands/relay.mdx | 6 ++---- 2 files changed, 16 insertions(+), 18 deletions(-) diff --git a/docs/cli/commands/gateway.mdx b/docs/cli/commands/gateway.mdx index 4ae660cf5..c2545e400 100644 --- a/docs/cli/commands/gateway.mdx +++ b/docs/cli/commands/gateway.mdx @@ -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,11 +361,11 @@ 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.** + **This command is to be deprecated and will be removed in a future release.** Please migrate to `infisical gateway start` for the new TCP-based SSH tunnel architecture. @@ -590,10 +590,10 @@ The Infisical CLI supports multiple authentication methods. Below are the availa - + - **This command is deprecated and will be removed in a future release.** - + **This command is to be 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 a81eda5d8..b377b9ce2 100644 --- a/docs/cli/commands/relay.mdx +++ b/docs/cli/commands/relay.mdx @@ -24,8 +24,6 @@ description: "Relay-related commands for Infisical" 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. -The relay system uses SSH reverse tunnels over TCP, eliminating firewall complexity and providing excellent performance for enterprise environments. - ## Subcommands & flags @@ -51,7 +49,7 @@ infisical relay start --host= --name= --auth-method= - The name of the relay. + The name of the relay. This is an arbitrary identifier for your relay instance. ```bash # Example @@ -69,7 +67,7 @@ Relays support all standard Infisical authentication methods. Choose the authent 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 relays. Below are the available authentication methods, with their respective flags. From 27529eb46b84b056c577471dd53307a0fc8c6017 Mon Sep 17 00:00:00 2001 From: Maidul Islam Date: Fri, 19 Sep 2025 09:52:50 -0400 Subject: [PATCH 12/12] correct lagacy commands --- docs/cli/commands/gateway.mdx | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/cli/commands/gateway.mdx b/docs/cli/commands/gateway.mdx index c2545e400..bddbf614c 100644 --- a/docs/cli/commands/gateway.mdx +++ b/docs/cli/commands/gateway.mdx @@ -363,10 +363,10 @@ sudo systemctl disable infisical-gateway # Disable auto-start on boot ## Legacy Gateway Commands - + - **This command is to be deprecated and will be removed in a future release.** - + **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. @@ -590,9 +590,9 @@ The Infisical CLI supports multiple authentication methods. Below are the availa - + - **This command is to be deprecated and will be removed in a future release.** + **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.