Seqrite Data Privacy Staging

Proxy for Remote Agents

Print Friendly, PDF & Email

On this page:

Introduction

As organizations continue to support remote and hybrid work environments, securing and managing endpoints outside the corporate network is critical.

SDP 3.2.0 introduces Remote Endpoint Scanning, enabling remote devices to securely communicate with SDP services without exposing internal infrastructure to the Internet. The solution uses a secure Proxy and Connector architecture, combined with Mutual TLS (mTLS), to provide authenticated and encrypted communication across all layers.

Business Benefits

Remote Endpoint Scanning enables organizations to:

  • Securely scan and manage remote devices.
  • Securely scan and manage remote devices.
  • Extend Data Privacy protection beyond the corporate network.
  • Maintain visibility and compliance for remote endpoints.
  • Eliminate direct Internet exposure of backend SDP services.
  • Support work-from-home and distributed workforce environments.
  • Enforce Zero Trust security principles through certificate-based authentication.

Enabling Proxy for Remote Agent

Once the proxy deployment is completed, the feature gets enabled.

System Requirement for Proxy and Connector

Supported Operating Systems

  • Ubuntu
  • RHEL (Red Hat Enterprise Linux)

Minimum Requirements

  • CPU: 2 vCPUs
  • RAM: 4 GB
  • Free Disk Space: 1 GB

Recommended Requirements

  • CPU: 4 vCPUs
  • RAM: 8 GB
  • Free Disk Space: 1 GB

Deployment Steps for Proxy and Connector

This section outlines the steps required to deploy the SDP Proxy and configure the sdp-connector to route traffic through it. The Proxy and Connector communicate securely via an encrypted control channel. To simplify deployment, the Connector dynamically generates a secure API key in MongoDB and packages it into a ready-to-deploy Proxy installation tarball.

Phase 0: Split DNS Configuration (Prerequisite)

Before deploying the Proxy, the customer’s DNS team must configure split-horizon DNS for the SDP domain (For example, sdp.customer.com) so the same name resolves differently depending on where the query originates. The sdp-connector runs as a pod inside the SDP Server’s cluster and is responsible for establishing the outbound tunnel to the Proxy — the domain itself continues to point at the SDP Server cluster for internal traffic.

  1. Internal DNS (On-prem DNS Server):

    Configure an A record (or multiple A records, if resolving to more than one node) for sdp.customer.com pointing to the SDP Server cluster’s master/ingress node IP(s). This ensures on-premises endpoints communicate directly with the SDP Server cluster without traversing the Proxy.

  2. Public DNS (For example, AWS Route 53 or Public DNS Zone):

    Configure an A or CNAME record for the same sdp.customer.com name pointing to the Proxy’s public IP — or to the WAF/ALB/Ingress address sitting in front of the Proxy, if one is used.

    • TTL: Set to 5 minutes (300 seconds) to allow rapid DNS propagation in case of failover or redeployment.
  3. Ownership:

    Both internal and public DNS records are configured and owned by the customer’s DNS team. The SDP team provides the target IP addresses / hostnames, but does not manage customer DNS infrastructure.

  4. Verification:
    • From inside the corporate network:

      nslookup sdp.customer.com

      Should return the internal SDP Server cluster node IP(s).

    • From outside the corporate network (For example, public internet or mobile hotspot):

      nslookup sdp.customer.com

      Should return the Proxy’s public IP or WAF/ALB address.

    Note: No secondary domain name is required. Only the resolved IP address differs based on network origin.

Phase 1: Download the Proxy Package

The sdp-connector provides a built-in API endpoint to generate and download a pre-configured proxy package. This package contains the necessary .deb and .rpm installers, installation scripts, and automatically embeds the correct api_key generated from MongoDB.

  1. Ensure the sdp-connector is running and connected to MongoDB (required to generate/fetch the ProxyAPIKey).
  2. Run the download script on a cluster node with kubectl access:

    /bin/sh download-proxy.sh

    This downloads proxy.tgz to your current working directory.

Phase 2: Install the SDP Proxy

Transfer the downloaded proxy.tgz archive to your dedicated Proxy host (For example, via scp or SFTP).

  1. Extract and Install
    1. Extract the tarball:

      tar -xzf proxy.tgz

    2. Run the installation script as root:

      sudo ./install.sh

    What the installer does:

    • Cleans up any previous proxy installations for a clean state.
    • Automatically detects the host OS (Debian/Ubuntu or RHEL/CentOS) and installs the appropriate .deb or .rpm package.
    • Injects the generated api_key into the proxy’s configuration file (/etc/sdp-proxy/proxy.yaml or /usr/local/dataprivacy/sdp-proxy/proxy.yaml).
    • Registers and starts the sdp-proxy systemd service.
  2. Configure TLS Certificates

    3. The SDP Proxy requires a valid public TLS certificate and private key to terminate HTTPS traffic on port 443 for end-users, agents, and the sdp-connector.

    1. Obtain your public certificate (server.crt) and private key (server.key).
    2. Copy them into the Proxy’s designated certificate directory:

      sudo cp server.crt /usr/local/dataprivacy/sdp-proxy/certs/server.crt
      sudo cp server.key /usr/local/dataprivacy/sdp-proxy/certs/server.key

    3. Restart the proxy service to apply the certificates:

      sudo systemctl restart sdp-proxy

    4. Verify the proxy service status:

      sudo systemctl status sdp-proxy

Phase 3: Configure the sdp-connector (connector-config.yaml)

With the proxy deployed, configure the sdp-connector to establish the reverse tunnel and push dynamic routing rules.

  1. Update connector-config.yaml

    Open connector-config.yaml and configure the connection parameters, remotes, and route definitions:

    # ── Proxy Connection Settings ────────────────────────────────────────────────
    # proxy_host: hostname in the proxy TLS certificate (checked via SNI/SAN)
    proxy_host: “sdp.customer.com”
    proxy_skip_verify: false
    # proxy_ip_list: public/reachable IP address(es) of the Proxy server
    proxy_ip_list:
    – “(Proxy_Public_IP)”
    # ── Reverse Tunnel Remotes ───────────────────────────────────────────────────
    # Establishes reverse tunnel: Proxy listens on port 8083 and forwards to internal SDP Server:443
    remotes:
    – “R:8083:(SDP_Server_Master_IP):443”
    # ── Route Configuration & Catch-All Whitelisting ─────────────────────────────
    routes:
    # 1. Public & Device Endpoints (Unrestricted IP, authenticated via mTLS / Token)
    # Specific routes match first via longest-prefix matching.
    – path: /kafka-cp/
    port: 8083
    require_mtls: true
    – path: /acs/v1/
    port: 8083
    require_mtls: true
    – path: /deviceRegistry/device/v2/deviceupdate
    port: 8083
    require_mtls: true
    – path: /deviceRegistry/
    port: 8083
    require_mtls: false
    – path: /dpcdn/
    port: 8083
    require_mtls: false
    # 2. Root Catch-All Route with IP Whitelisting
    # Matches any path NOT covered by more specific routes above (For example, /dashboard, /admin, web UI).
    # RESTRICTED: Only clients matching allowed_ips can access these endpoints.
    – path: “/”
    port: 8083
    require_mtls: false
    allowed_ips:
    – “1.1.1.1” # Corporate NAT gateway / Office public egress IP

  2. Update the Kubernetes ConfigMap

    Apply the updated configuration to the running cluster:

    kubectl delete cm connector-config -n sdp-connector
    kubectl create cm connector-config –from-file=connector-config.yaml -n sdp-connector

  3. Restart the sdp-connector.

Phase 4: Verification

  1. Check Connector Logs

    2. Verify that the tunnel is established and the routes (including the catch-all) are pushed:

    kubectl logs -n sdp-connector -l app=sdp-connector -c sdp-connector –tail=50

    Expected log indicators:

    tunnel established — remotes: [“R:8083 (SDP_Server_Master_IP):443”] successfully pushed certificate and key to proxy over control channel
    successfully pushed 20 routes to proxy over control channel

  2. Check Proxy Logs

    On the proxy server, verify that the control session registered the routes and applied IP whitelisting:

    sudo tail -f /var/log/sdp-proxy/proxy.log

    Expected output:

    [session#1] registered client CA cert and control channel server cert via control channel
    [session#1] dynamically registered 20 routes via control channel

  3. Verify Catch-All Access Control
    1. From an Unauthorized IP (For example, mobile hotspot / non-whitelisted IP):

      curl -v -i https://sdp.customer.com/

      Expected Response:

      HTTP/1.1 403 Forbidden
      Content-Type: application/json
      X-Sdp-Error: route_ip_denied
      {“error”:”Forbidden: access denied for this IP on this route”}

  4. From an Authorized Whitelisted IP (For example, corporate VPN / office):

    curl -v -i https://sdp.customer.com/

    Expected Response:

    HTTP/1.1 200 OK
    …

Was this page helpful?
Yes No