Delegate Requirements and Limitations
This topic lists the limitations and requirements of the Harness Delegate.
In this topic:
- Before You Begin
- Delegate Limitations
- System Requirements
- Whitelist Harness Domains and IPs
- Network Requirements
- Permissions and Ports
- Add Certificates and Other Software to Delegate
- Delegate Access Requirements
Before You Begin
- Deployment limits: Deployment limits are set by account type.
- You might need to install multiple Delegates depending on how many Continuous Delivery tasks you do concurrently, and on the compute resources you are providing to each Delegate. Typically, you will need one Delegate for every 300-500 service instances across your applications.
A service instance is when you use Harness to deploy the underlying infrastructure for the instance.
For example, an instance of a Kubernetes workload where Harness creates the pods, or an instance of an ECS task where Harness creates the service for the task.
The Delegate is installed in your network and connects to the Harness Manager.
One Delegate size does not fit all use cases, so Harness let's you pick from several options:
Remember that the memory and CPU requirements are for the Delegate only. You Delegate host/pod/container will need more computing resources for its operations systems and other services such as Docker or Kubernetes.
The Delegate runs on a Linux/UNIX server or container.
Ensure that you provide the minimum memory for the Delegate and enough memory for the host/node system. For example, an AWS EC2 instance type such as m5a.xlarge has 16GB of RAM, 8 for the Delegate and 8 for the remaining operations.
The Shell Script Delegate requires cURL 7.64.1 or later.
Access to artifact servers, deployment environments, and cloud providers. As shown in the following illustration:
Whitelist Harness Domains and IPs
- Harness SaaS (required): Harness Delegates only need outbound access to the Harness domain name (most commonly, app.harness.io) and, optionally, to logging.googleapis.com. The URL logging.googleapis.com is used to provide logs to Harness support.
- Harness Manager: users of the Harness Manager browser client need access to app.harness.io and static.harness.io. This is not a Harness Delegate requirement. It's simply for users to use the browser-based Harness Manager.
- Vanity URL: if you are using a Harness vanity URL, like mycompany.harness.io, you can whitelist it also.
- Optional: whitelist Harness SaaS IP
18.104.22.168. Harness will not change this IP without 14 days notice to all customers. If a security emergency requires a change, all customers will be notified.
The following network requirements are for connectivity between the Harness Delegate you run in your network and the Harness Manager (SaaS or On-Prem), and for your browser connection to the Harness Manager.
- HTTPS port 443 outbound from the Delegate to Harness.
- HTTP/2 for gRPC (gRPC Remote Procedure Calls)
- Delegate requirements: The Delegate will need API/SSH/HTTP access to the providers you add to Harness, such as:
- Cloud Providers.
- Verification Providers.
- Artifact Servers (repos).
- Source repositories.
- Collaboration Providers.
- SSH access to target physical and virtual servers.
Permissions and Ports
Add Certificates and Other Software to Delegate
For steps on adding certs or other software to the Delegate, see Common Delegate Configuration Scripts.
Delegate Access Requirements
- The Harness Delegate does NOT require root account access, but the Kubernetes, ECS, and Docker Delegates run as root by default. This is to enable the Delegate to install applications using Delegate Profiles (apt-get, etc). If you do not need to install applications using Delegate Profiles, then you can use a non-root account or install the application without the Delegate.
- If you do not run the Delegate as root, be aware that you cannot install any software using a Delegate Configuration script.