Private Locations — Frequently Asked Questions¶

Resource Management¶

Can Private Locations be deployed on Windows, or are Linux/Kubernetes required?¶

While Kubernetes deployments using the Helm chart provided by Escape are recommended for production environments, they are not required.

Private Locations can be deployed on Windows as a standalone binary, either running as a Windows service or directly in a terminal. The latest builds for Windows and macOS are available on the release page.

Alternatively, the repository can be cloned and the binary can be built manually for custom deployment scenarios.

Are additional resources needed beyond the recommended configuration based on traffic volume?¶

Yes, resource requirements scale with traffic volume. While the basic configuration (1 vCPU, 2GB RAM) is sufficient for initial deployments, resources may need to be scaled based on the following factors:

• Number of concurrent scans: Multiple simultaneous scans require additional resources
• Volume of scan requests: Higher request volumes increase memory and CPU demands
• Integration complexity: Complex authentication workflows and custom configurations require more processing power
• Network latency: Higher latency may require additional resources to maintain throughput

Private Location performance should be monitored through the logging and monitoring capabilities. For assistance with capacity planning and scaling strategies, contact the support team.

How many Private Locations are needed depending on the number of scan profiles?¶

The determining factor is not the total number of scan profiles, but rather the number of scans running concurrently.

Capacity planning examples:

• Sequential scans: For 50 scan profiles that run at different times, a single Private Location is sufficient.
• Concurrent scans: For 10 scans configured to run simultaneously, multiple Private Locations may be required depending on:
  • The size and complexity of the APIs being scanned
  • The resources allocated to each Private Location
  • The expected scan duration and throughput requirements

Is it better to deploy multiple Private Locations or increase resources on a single instance?¶

The optimal scaling strategy depends on the specific use case and workload characteristics:

Vertical scaling (increasing resources on a single Private Location):

• Advantages: Simpler configuration and management, lower operational overhead, suitable for moderate workloads
• Best for: Organizations with sequential or moderately concurrent scans, predictable workload patterns
• Limitations: Single point of failure, resource ceiling based on hardware constraints, potential performance degradation under extreme load

Horizontal scaling (deploying multiple Private Locations):

• Advantages: High availability and fault tolerance, better load distribution, easier to scale incrementally, no single point of failure
• Best for: Organizations with high-concurrency requirements, distributed teams across multiple networks, mission-critical operations requiring redundancy
• Considerations: Requires load balancing configuration, higher operational complexity

Recommended approach:

1. Start with vertical scaling by increasing resources on a single Private Location to meet initial demand
2. Monitor performance metrics through the logging and monitoring capabilities to identify bottlenecks
3. Deploy additional Private Locations horizontally when:
   • A single instance consistently reaches resource limits (CPU, memory)
   • High availability is required to eliminate downtime
   • Scans need to be distributed across different network zones or regions
   • Concurrent scan requirements exceed what vertical scaling can reasonably provide

Availability & Connectivity¶

Does the Private Location restart automatically if it disconnects?¶

Yes, the Private Location includes automatic restart capabilities. When deployed using Docker Compose or Helm with the restart: always policy configured, the service will automatically restart upon disconnection or failure.

This ensures high availability and minimal downtime for scanning operations.

Does the Private Location turn off after a period of inactivity?¶

No, the Private Location remains active indefinitely as long as it maintains connectivity to the Escape platform. The service continuously sends heartbeat signals to the Escape platform at regular intervals (approximately every second) to maintain its connection status and ensure availability for incoming scan requests.

The Private Location will only stop if explicitly terminated or if it loses network connectivity to the Escape platform.

What type of traffic goes through port 80, and can it be disabled?¶

Port 80 serves as a fallback connection method when SSH connections through port 2222 are unavailable. This fallback mechanism was primarily designed for legacy Repeater deployments and can be safely disabled in modern configurations without affecting normal operations.

When port 80 is disabled, all traffic will route through secure channels (SSH on port 2222), which is the recommended configuration for production deployments.

Health Monitoring¶

How does Escape determine if a Private Location is alive and operational?¶

Escape monitors Private Location health through a multi-layered approach:

• Regular heartbeats: The Private Location sends periodic health checks to the Escape platform (approximately every second) to signal operational status
• Connection status tracking: The platform continuously monitors the connection state and availability of each Private Location
• Performance monitoring: Escape tracks response times and success rates of scan requests to detect performance degradation

Private Location health and performance can be monitored through the Escape platform's Private Locations dashboard, and additional monitoring can be implemented using the logging and monitoring capabilities.

Can automatic restarts be configured if the Private Location disconnects?¶

Yes, automatic restart on disconnection is supported and can be configured based on the deployment method:

Helm deployment (recommended): By default, Helm deployments include automatic restart functionality. This behavior can be customized by updating the livenessProbe configuration in the Helm values.

Other deployment methods: The HEALTH_CHECK_PORT environment variable should be set to a port number greater than 1000 (the container should not run as root). Once configured, custom monitoring can be implemented by querying the /health endpoint and triggering restarts as needed based on the health status.

Troubleshooting¶

If connectivity issues are experienced or troubleshooting is needed for a Private Location, the following steps should be followed:

1. Verify deployment configuration: The deployment configuration should be checked to ensure the API key is correctly set and has not expired
2. Review firewall settings: Firewall settings should be verified to allow the necessary outbound connections to the Escape platform
3. Check SSL/TLS configuration: The SSL/TLS configuration should be reviewed to ensure certificates are valid and properly configured for secure connections
4. Analyze logs: Logs should be monitored and analyzed using the logging and monitoring tools to identify specific error patterns or connection issues
5. Contact support: If issues persist after following the above steps, the support team should be contacted with relevant log excerpts and configuration details for further assistance