• Documentation
    • Search documentation
    karat

    +

    K

    API Reference ↗
    Management & enablementEnrollment settingsConfigure egress

    Configure network egress

    Network egress refers to any network traffic originating from within Foundry that attempts to connect to an external system. This page outlines how network egress is configured and managed in Control Panel and how those configurations are consumed by user workloads in Foundry.

    Network ingress refers to network traffic originating outside of Foundry that attempts to establish a connection to Foundry. Network ingress is also managed in Control Panel.

    Network egress overview

    Foundry provides strict network firewalls to protect customer data. Customer-managed network egress policies are used to apply network firewall rules to individual workloads using container networking technology (Cilium ↗, eBPF ↗). In addition to these customer-specific rules, Palantir's Information Security team maintains network firewall rules at the infrastructure proxy level to provide another layer of security. Together, these rules govern the network egress execution of user workloads in Foundry, including the following:

    Network traffic that egresses from Foundry may still cause data to flow in either direction. This means that workloads within Foundry that are allowed to connect externally may be used to both sync and export data.

    Opening a network egress route is always a security risk. Information security officers for a Foundry enrollment should ensure that they only open network routes to trusted destinations, and limit access to those routes to a trusted group of developers. Even a trusted external system can be abused by malicious actors to bypass security controls. Information security officers should leverage Foundry change management tools to ensure changes to egress logic are reviewed by a trusted group, and establish audit processes to ensure egress logic remains secure.

    Network egress policies represent the set of external destinations that user workloads may egress to from a Foundry enrollment, and are configured in Control Panel.

    Multiple egress policy types exist to represent different network paths from Foundry to external systems.

    The destination of a network egress policy cannot be modified once the policy has been created. Network egress policies cannot be deleted after creation, they may only be revoked.

    Direct connection egress policies

    Direct connection policies enable connections where egress can be made directly from Foundry's network to the external destination. In the case of Foundry instances hosted in the cloud, this will mean connections made over the Internet, such as REST APIs or systems hosted in the cloud. In the case of on-premise Foundry instances however, this will mean connections to systems connected to the on-premise network itself.

    The external system must allow inbound connections from Foundry.

    The following list summarizes the options that may be used when configuring direct connection egress policies.

    OptionDescription
    AddressOption 1: DNS
    A domain name in the format subdomain.domain.com. Only the specific domain name will be allowed, and wildcards are not supported. For example, to allow traffic to both foo.mycompany.com and bar.mycompany.com, two separate domain name policies must be created.

    Option 2: IP
    A single IPv4 address in the format x.x.x.x

    Option 3: CIDR
    An IPv4 CIDR address block in the format x.x.x.x/x
    Port(s)The port or port range that should be allowed for the specified domain. Port values must be in the range of 1 - 65535 inclusive.

    Option 1: Single port
    When using a DNS address, you must specify a single port.

    Option 2: Port range
    When using this option, you must provide a starting and ending port, where the starting port is less than or equal to the ending port.

    Server Name Indication (SNI) verification

    Palantir's network infrastructure attempts to perform SNI verification by default for all network connections using port 443 (default HTTPS port). If the traffic over that port does not have SNI, which is the case for some protocols like FTP(S), SFTP, and most TCP-based database connections, you may encounter hanging connections and/or timeout errors.

    If you expect non-HTTPS traffic om port 443 for a given policy, administrators have the ability to disable SNI verification on that policy.

    Agent proxy egress policies [Beta]

    Beta

    Creating and using agent egress policies is in the beta phase of development and may not be available on your enrollment. Functionality may change during active development.

    Agent proxy egress policies enable connections to on-premise or privately hosted systems over a Data Connection agent. Agent proxy egress policies allow Foundry workflows to function as if they were directly connecting to the external system directly, without requiring any additional configuration; all the traffic is transparently proxied via the agent.

    With this scenario, no inbound connections are initiated from Foundry to the external system, and the external system does not need to allow inbound connections from Foundry.

    However, the agent host machine must have outbound network connectivity to the target external system, and the target external system must allow inbound connections from the agent host.

    Sources using agent egress policies are supported in the following workflows:

    The following list summarizes the options that may be used when configuring agent proxy egress policies.

    OptionDescription
    AddressThe external system domain name in the format subdomain.domain.com. Only the specific domain name will be allowed, and wildcards are not supported. For example, to allow traffic to both foo.mycompany.com and bar.mycompany.com, two separate domain name policies must be created.
    Port(s)The port or port range that should be allowed for the specified domain. Port values must be in the range of 1 - 65535 inclusive.

    Option 1: Single port
    When using a DNS address, you must specify a single port.

    Option 2: Port range
    When using this option, you must provide a starting and ending port, where the starting port is less than or equal to the ending port.
    Agent(s)The agent(s) to be used to connect to the external system. If more than one agent is specified, traffic will be assigned randomly to one of the agent in the list.

    Limits

    You can import a maximum of 10 sources into a code resource or a transform, with up to 50 agent proxy egress policies combined.

    Using a policy

    This section summarizes the relevant permissions for network egress policies, the potential lifecycle states that a network egress policy can be in, and describes how to apply a network egress policy.

    Permissions

    The below table shows a summary of the operations that are relevant for network egress policies and the default configuration of these permissions.

    OperationDescription
    ProposeAny Foundry user may propose a network egress policy. Proposed policies only become active and usable once they are approved. Policies pending approval are visible in the Approvals inbox in Control Panel.
    Approve/CreateGranted via the Manage network egress configuration workflow. By default, this workflow is then granted to both Enrollment Administrator and Information Security Officer roles.
    Update metadataGranted via the Manage network egress configuration workflow. By default, this workflow is then granted to both Enrollment Administrator and Information Security Officer roles.
    RevokeGranted via the Manage network egress configuration workflow. By default, this workflow is then granted to both Enrollment Administrator and Information Security Officer roles.
    PausePalantir's Information Security team has the ability to block network egress that are deemed a security risk or threat. Any network egress policies blocked by this will appear as Paused in Control Panel. If you believe a legitimate network egress policy for your enrollment has been incorrectly paused, file a support ticket with the relevant details.
    ViewAllows assigned users and groups to see the existence of the policy, but does not allow them to import and use it in any workloads. In general, we recommend making anyone who might ever need to use the policy a viewer, even if they are not currently an importer.
    ImportAllows assigned users and groups to see the existence of the policy and to import and use within workloads.

    The primary management interface for network egress lives at the enrollment level in Control Panel. Users with access to the Manage network egress configuration workflow, associated with the Enrollment administrator role, will be able to access the Network Egress page to perform any administrative actions on egress policies.

    Enrollment Administrators and Information Security Officers are additionally always able to see which projects an egress policy has been imported into. This is possible regardless of the individual access of the administrative user's access to the project(s). This metadata is available to ensure that Information Security Officers have sufficient visibility into policy usage to take governance decisions on possibly revoking or otherwise restricting the ability for a policy to be used.

    When approving a policy, the Information Security Officer must decide which users or groups should be granted the ability to either View or Import the network egress policy. This may also be managed later in Control Panel using the Manage Sharing button on the policy details page.

    By default, policies are "opt-in" and must be attached to a workload in Foundry. For example, when creating a data connection source, policies for that source should be explicitly attached to the source by a user with Importer permission on the policy. This follows the principle of least privilege ↗, ensuring that workloads are only granted egress rules that are strictly required for that workload to run successfully.

    Users with Import access to a network egress policy can run arbitrary code in Foundry that talks to the destination address. Ensure that any users granted Import permissions are trusted and trained on your organization's information security policies to avoid misuse of this access.

    Policy states

    Throughout the lifecycle of a network egress policy, it may be in one of the various states described below:

    Policy stateDescription
    Pending approvalPending approval is the default state for new network egress policies. Policies in this state can be attached to workloads, but workloads attempting to use a pending approval policy will fail to run.
    ActiveOnce a policy is approved, it becomes active. Importers of an active policy are able to attach it to Foundry workloads to allow that workload to egress to the specified external address.
    PausedPalantir's Information Security team has blocked egress to the specified address. Workloads attempting to use a paused policy will fail to run.
    RevokedInformation Security Officers for a Foundry enrollment may revoke a policy from Control Panel. Workloads attempting to use a revoked policy will fail to run.

    Common edge cases

    What happens when there are two policies that are identical; one is paused/revoked and the other is active.

    Any workloads using the active policy will run successfully, while workloads attempting to use the paused/revoked policy will fail to run.

    What happens if there are overlapping policies and one is paused/revoked and the other is active?

    This may happen if a policy using a single IP address and a policy specifying a CIDR block of IP addresses overlap.

    In this case, as with identical policies, any workloads using the active policy will run successfully, while workloads attempting to use the paused/revoked policy will fail to run.

    What happens if I propose a policy that already exists?

    Duplicate policies are allowed, and the information security officer reviewing the proposal may choose to do one of the following:

    1. Deny the proposal entirely
    2. Deny the proposal and grant the proposer Importer access to an existing identical or overlapping policy
    3. Approve the proposal and allow duplicate or overlapping policies (not recommended)

    Apply a policy

    Two steps must be taken for a network policy to take effect.

    First, create the policy in Control Panel. If your Foundry installation's policy management is managed by Palantir, contact your Palantir representative with the details of your egress policy. This allows Palantir to assess security risks before expanding network access. If your Foundry installation's policy management is fully self-service, the policy will automatically be applied to the firewalls.

    Second, the policy must also be assigned to a user workload:

    • Data Connection sources using a direct connection runtime: Specify the network policy when creating a new source.
    • Code Workbook: Granular network management is not yet available, and administrators must instead create a global policy. A global policy is applied indiscriminately to all workloads and should only be configured for highly trusted network routes.

    To assign a policy to a user workload, the Importer permission is required for the specific egress policy. This permission is granted on a per-policy basis through the Manage Sharing setting on the respective egress policy.

    Dialog for setting permissions on egress policy

    Which IPs do connections from Foundry come from?

    When connections are initiated from Foundry to external destinations, they come from certain IP ranges. Sometimes those IPs need to be added to an allowlist before connections from Foundry will be accepted.

    When Foundry is hosted in Palantir's cloud infrastructure, the egress IPs where Foundry traffic originates will be displayed on the network egress management page in Control Panel. You should copy the CIDR ranges displayed there when adding to an allowlist in the destination system.

    Note that connections through agents are handled differently. When using an agent, network traffic to the source system will always come from the agent host on your infrastrucutre; it is your responsibility to ensure network connectivity between the agent and target systems.

    Amazon S3 bucket policies

    For Foundry instances hosted in AWS, additional configuration is required when connecting to S3 buckets in the same region. This is due to how AWS handles networking for requests to S3 from a VPC gateway endpoint in the same region.

    To check if your connection requires extra configuration, navigate to the Network egress page in Control Panel. If you find an additional tab called S3 bucket policies, then your instance is hosted in AWS and you must explicitly allow traffic from Palantir's VPC endpoint to any S3 buckets in the same region.

    If present, the S3 bucket policies tab will also display the region where your instance is hosted, along with the Amazon Reference Number (ARN) of the VPC endpoint used to route traffic from Foundry to any same-region S3 buckets.

    Control Panel configuration page for same region S3 bucket policies

    To successfully connect to a bucket in the same region as Foundry, you must complete the following:

    1. Configure your bucket policy in the AWS console to allow traffic from the VPC endpoint for your Foundry instance. Learn more about AWS bucket policies ↗.
    2. Ensure that your desired bucket is listed under Network egress > S3 bucket policies > AWS S3 Bucket Policies in Control Panel.
    3. Create an appropriate network egress policy as described above, and add it to the configuration details of the Data Connection source you are using to connect.

    Allow traffic to S3 from the VPC endpoint for your Foundry instance

    In the AWS console, you must ensure that the bucket policy ↗ for your S3 bucket allows inbound traffic from the VPC endpoint displayed in the Network egress > S3 bucket policies tab, as shown below:

    A Control Panel page displaying the VPC endpoint for a Foundry instance

    The Amazon S3 documentation contains an example ↗ of how a bucket policy may be used to restrict traffic to an S3 bucket to a specific VPC endpoint. To learn more about managing inbound traffic to S3 from VPC endpoints, review the official AWS documentation ↗.

    You can configure AWS bucket policies to gate traffic based on the VPC endpoint where the traffic originates. However, you should always use some form of access authentication to provide security for your bucket, as multiple Foundry instances may share a single VPC endpoint. A bucket policy that allows access purely based on the VPC endpoint may allow unauthorized access by users outside your organization.

    Add an S3 bucket policy

    To add a same-region bucket, select Add bucket policy and follow the prompts to enter your desired bucket name, as shown below:

    Dialog showing the inputs required to add a new same-region S3 bucket policy

    The form will automatically check for a valid bucket name, as well as the region. If a valid bucket name matches the region where your Foundry instance is hosted, you will be able to save. In addition to the bucket name, you must provide a policy of READ ONLY or READ WRITE. This dictates what level of access you would like Palantir to request when establishing a connection to S3.

    The addition of same-region S3 buckets to the allowlist, as well as the desired bucket access policy, should be treated as a minimum level of access guaranteed to be available over the VPC endpoint for your Foundry instance.

    Data in S3 should be secured with appropriate authentication and authorization in AWS, as well as network egress policy governance within Foundry.

    Palantir may expand the provided list to allow access to additional same-region buckets and may also bump up the access policy for a given bucket from READ ONLY to READ WRITE. Proper authentication and authorization when using the S3 source type will ensure that you do not accidentally allow unauthorized Foundry users to access your S3 bucket(s).

    Use an S3 bucket policy

    Once added, same-region bucket policies take effect immediately and apply to all workloads attempting to egress directly from Foundry to that bucket. Unlike network egress policies, they do not need to be attached to specific sources or other workloads in Foundry.

    When creating an S3 source, the configuration interface automatically checks if the bucket is in the same region as Foundry and if the bucket has already been added in Control Panel. Users configuring the source will see either a green check indicating that the bucket is added correctly, or a red check indicating that action is required by an administrator with access to add an S3 bucket policy in Control Panel.

    Limits

    You can add up to a maximum of 10 same-region buckets per enrollment. Contact Palantir Support If you require access to more than 10 same-region S3 buckets from your Foundry instance.

    Microsoft Azure Storage policies

    For Foundry instances hosted in Azure, additional configuration is required when connecting to Azure Storage resources as traffic is routed over Azure service endpoints.

    To check if your connection require extra configuration, navigate to the Network egress page in Control Panel. If you find an additional selectable tab called Azure Storage policies, then your instance is hosted in Azure and you must explicitly allow traffic from Palantir's Azure subnets to any Azure Storage account with connected resources.

    If present, the Azure Storage policies tab will display the subnet IDs that are used to route traffic from Foundry to any Azure Storage resource.

    The Control Panel configuration page for Azure Storage policies.

    To successfully connect to an Azure Storage resource, you must complete the following:

    1. Configure your Azure Storage account's virtual network rules in Azure to allow traffic from the subnets for your Foundry instance. Learn more about managing Azure virtual network rules↗.
    2. Ensure that your desired Azure Storage account is listed under Network egress > Azure Storage policies in Control Panel.
    3. Create an appropriate network egress policy as described above, and add it to the configuration details of the Data Connection source you are using to connect.

    Allow traffic to Azure Storage account from the subnets of your Foundry instance

    In your Azure account, you must ensure that the virtual network rules ↗ for your Storage account allows inbound traffic from the subnet IDs displayed in the Network egress > Azure Storage policies tab, as shown below:

    A Control Panel page displaying the subnets of a Foundry instance.

    You can configure Azure Storage policies to gate traffic based on subnet IDs. However, you should always use some form of access authentication to provide security for your Azure Storage account, as multiple Foundry instances may share the same subnets. An Azure Storage policy that allows access purely based on the subnet IDs may allow unauthorized access by users outside your Organization.

    Add an Azure Storage policy

    To add a Azure Storage egress policy, select Add Azure Storage policy, and follow the prompts to enter your desired Storage account resource ID, as shown below:

    Dialog showing the inputs required to add a new Azure Storage policy.

    The form will automatically check if the provided Azure Storage account resource ID is valid. You can find more information on how to find an Azure Storage account resource ID in the Azure documentation ↗.

    Use an Azure Storage policy

    Once added, Azure Storage policies take effect immediately and apply to all workloads attempting to egress directly from Foundry to that Storage account. Unlike network egress policies, they do not need to be attached to specific sources or other workloads in Foundry.

    When creating an ABFS source, the configuration interface automatically checks if the Foundry is deployed on Azure and if there is a valid Storage account that has already been added in Control Panel. Users configuring the source will see a warning indicating that action is required by an administrator with access to add an Azure Storage policy in Control Panel, as shown below.

    A warning indicating that this source requires an Azure Storage policy.

    Following the creation of a network egress policy, if an Azure Storage policy is also required to egress, a warning is also displayed as shown below:

    A warning indicating that this network policy requires an Azure Storage policy.

    Google Cloud Platform (GCP) egress

    For Foundry instances hosted in GCP, additional configuration is required when connecting to resources also hosted on GCP projects, such as BigQuery, Google Cloud Storage, and Google Pub/Sub.

    To set up the additional configuration needed for GCP projects, contact Palantir Support for assistance.