> For the complete documentation index, see [llms.txt](https://docs.prismacloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prismacloud.io/content-collections/application-security/manage-network-tunnel/transporter-connectivity-overview.md).
# Transporter Connectivity Overview
The Transporter acts as a network tunnel that allows you to create a secure communication channel between Prisma Cloud and your self-hosted version control systems (VCS)/Terraform Enterprise (Run Tasks) that do not allow inbound network traffic. To establish this communication channel, two components are required:
* **Prisma Cloud Transporter Client**: A Docker container running in your environment with access to VCS/Terraform Enterprise (Run Tasks) isolated from inbound network traffic
* **Prisma Cloud Transporter Server**: Pre-enabled access to the server
After configuring Transporter, Prisma Cloud authenticates the connection, establishing a communication channel through WebSocket.
This overview describes Transporter connectivity, including browser connectivity and proxy connectivity for both Docker and Kubernetes setups.
## Transporter Connectivity
The Transporter requires the following network access:
* Internet access to the Prisma Cloud platform. The Transporter Client (Client) is restricted to outbound traffic for internet access to the Prisma Cloud platform, allowing egress only towards the Prisma Cloud Tenant (Tenant). The Tenant does not initiate traffic to the Client. Therefore the Tenant does not need to know the public IP of the Client and does not need to be able to access the Client directly. The Client establishes a web socket tunnel on port 443, and the Tenant responds on the same port, creating a VPN tunnel over port 443 between the Client and the Server. Once the network tunnel is created, the connection becomes secure, enabling bi-directional communication between the Client and Server.
* Access to the Transporter Client IP on the designated port (default: TCP-8000). This connection facilitates the interaction between the browser and the Transporter Client
* Access to the VCS/Terraform Enterprise (Run Tasks) is on ports 80 and 443
The following diagram describes Transporter connectivity in a Docker environment.
**Legend**
| **Legend** | - |
| ------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| | Secure communication and data transfer from Transporter Client (Docker Container) and Prisma Cloud Tenant via port 443 |
| | Receive webhook events by the Docker Container from the VCS on the specified port (default: 8000) |
| | Secure communication and data transfer between the Docker Client and VCS Server on port 443 |
The following diagram describes Transporter connectivity in a Kubernetes environment. You can configure the VCS server either inside or outside the cluster.
The legends for the Kubernetes and Docker diagrams (see above) are identical.
## Browser Connectivity
To facilitate the Prisma Cloud Transporter integration, the browser that performs the setup must meet specific network access conditions.
The following diagrams describe browser connectivity in both Docker and Kubernetes environments.
| **Legend** | - |
| ------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| | Browser requires internet access to the Prisma Cloud platform on port 443 |
| | Browser requires access to the Transporter Client IP on the designated port (default: TCP-8000). This connection facilitates the interaction between the browser and the Transporter Client |
| | Browser requires access to the VCS on port 443 |
## Proxy Connectivity
When employing a proxy within the Prisma Cloud Transporter setup, it acts as a gateway, necessitating the Transporter Client configuration to recognize the proxy’s presence. This is achieved by setting environment variables during Transporter Client execution, ensuring that traffic is routed through the proxy rather than directly connecting to the Prisma Cloud Tenant.
In some cases, proxies go beyond simply relaying traffic and actively inspect traffic passing through port 443. They may evaluate the traffic and decide whether to allow it or not. This necessitates providing the proxy with the client certificate when communicating through it. The client certificate serves as a trusted identifier, enabling the proxy to verify the client’s authenticity and facilitate secure communication. Transporter supports deployment through a proxy for both Docker and Kubernetes configurations.
The following diagrams describe Transporter connectivity through a proxy in a Docker environment.
NOTES:
* In the first diagram, the connection between the VCS and Docker Container does not pass through the firewall, while in the second diagram, the connectivity between the VCS and Docker Container passes through a firewall
* The connectivity legend for the proxy matches with the Transporter connectivity legend above, except that traffic passes through the firewall from the Transporter Client to the Proxy, and then to the Prisma Cloud Tenant
For detailed information about the proxy setup for Transporter in a Docker Container deployment refer to [Docker Proxy Connectivity](/content-collections/application-security/manage-network-tunnel/deploy-transporter-docker.md#docker-proxy-integration-).
The following diagram describes Transporter connectivity in a Kubernetes environment. You can configure the VCS server either inside or outside the cluster.
The legend detailing connectivity in the Kubernetes diagram matches the legend used for Docker Containers above
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.prismacloud.io/content-collections/application-security/manage-network-tunnel/transporter-connectivity-overview.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.