This page describes the configuration options available when using an agent as a network proxy via agent proxy egress policies on Foundry worker connections and assumes you are already familiar with data connection agents and their generic configuration options.
Agents used as a proxy provide a network path for services in Foundry to access systems within a separate network that are not directly accessible over the Foundry network. When Foundry is hosted in the cloud, a proxy is required to access systems which are not accessible over the Internet. When Foundry is hosted on a private network, a proxy is required to access systems in other networks, which may include the public Internet if otherwise not accessible.
Agent proxies allow applications in Foundry to operate as if they are connecting to a source directly over the Foundry network, and they can be configured with multiple agents to allow for alternating maintenance windows that prevent downtime. Follow the guide below to configure and manage an agent used as a proxy.
You must first set up an agent before using it as a proxy. An existing agent already used for agent worker sources can be reused without additional configuration.
Once an agent has been set up, create an agent proxy egress policy using that agent. You can then create a source and assign that policy to it.
To ensure that connections over the proxy only have access to required resources, a number of security controls are available.
Security controls are either mandatory and cannot be disabled, or optional and are not enabled by default.
The following security control configurations are available:
| Security control | Required? | Description |
|---|---|---|
| Source configuration enforcement | Yes | The agent proxy always restricts traffic to only the hostname(s) and port(s) configured on the assigned source. |
| Agent allowlist (Foundry) | Optional | Configure an allowlist in Foundry to filter traffic before it reaches the agent. Only agent resource owners can modify this setting. |
| Agent allowlist (local file) | Optional | Create an allowlist on the agent host for the local agent process to enforce within your network. Only users with SSH access to the agent host can modify this setting. |
| Agent host firewall | Optional | Set up host-level firewall controls to limit agents to communicating only with intended target systems (strongly recommended). These firewalls work independently of Foundry and add an extra security layer. |
The hostname and port in the URL defined on the source restrict access to only that hostname and port when connecting to the agent proxy. Attempts to connect to any other hostname or port will result in an HTTP 403 (Unauthorized) response code from the proxy.
This prevents unauthorized connections when importing and using the connection in code.
If only this security control is used, ensure that users who are able to assign an agent to a particular source are also trusted to connect to any system that is reachable from the agent host.
Configure an allowlist in Foundry to restrict connections to specific IP addresses or CIDR blocks for a specific agent, regardless of assigned sources.
To configure this, navigate to Agent settings, then toggle the Advanced option in the Manage Configuration section. In the YAML file, add a block for agentProxyConfiguration at the same indentation level as the security block.
List the CIDR blocks and ports where you want to allow agent connections. For example:
Copied!1 2 3 4 5 6 7agentProxyConfiguration: allowListedCidrs: - cidrBlock: '192.168.1.1/32' port: 7000 endPort: 9000 - cidrBlock: '192.168.2.2/24' port: 443
The same configuration used for an agent allowlist in Foundry can also be set in a file on the agent host itself, preventing users in Foundry from editing the configuration.
To configure an agent allowlist locally, follow the steps below:
agentProxyConfig in the same directory that contains your magritte-bootvisor-<version> (the root folder).agentProxyConfig folder, create a file named agentProxyConfig.yml.agentProxyConfig.yml file and agentProxyConfig folder must be created with the root user, and the file permissions must be set to prevent the agent from writing to this file or folder. The agent will not run the agent proxy feature if the agentProxyConfig.yml file exists and is writeable, or if one of the parent directories is writeable by the agent.For example:
Copied!1 2 3 4 5 6allowListedCidrs: - cidrBlock: '192.168.1.1/32' port: 7000 endPort: 9000 - cidrBlock: '192.168.2.2/24' port: 443
As for any agent, we recommend setting a firewall on the host to restrict connectivity to only what is necessary.