Integration security
This page explains how data moves between Port and your tools, how action triggers reach your infrastructure, and where integrations process your data.
Data flow
Data into the system
You can send data to Port through its API, Ocean integrations, Git provider apps, webhooks, and other interfaces. Data ingestion uses a push model: Port does not independently query your infrastructure to pull information for ingestion.
All ingestion methods encrypt data at rest and in transit. Port requires authentication before accepting and processing requests that send data to it.
Data out of system
You can access data in Port through the Port application and REST APIs. Port does not make outbound requests to your infrastructure to pull information.
For self-service actions and automations, you choose a backend that determines how Port sends trigger requests:
| Backend | Connection model |
|---|---|
| Kafka | You listen for action triggers on a Port-provided Kafka topic, without opening inbound connectivity to your infrastructure. |
| Port agent | You host the agent on your premises. It listens to the Kafka topic and forwards triggers to the appropriate internal destination, without opening inbound connectivity. |
| Webhook | You allow Port to send requests directly to your environment to trigger your backend. |
Port attaches security headers to trigger requests for every backend so you can validate that requests originated from Port.
Kafka access and message validation
Kafka is publicly accessible. Each customer connects with dedicated credentials and has access control list (ACL) permissions to read dedicated topics.
Each customer has a dedicated Kafka topic containing messages scoped to that customer. Messages use a consistent format and include a signature you can validate with your secret credentials to confirm they originated from Port.
Network connections and outbound IP addresses
In the architecture diagram, customer-hosted Ocean integrations make outbound-only requests to Port's API gateway to populate your catalog. The depicted architecture requires no inbound connections to your environment.
All HTTPS communication uses REST APIs over port 443 and enforces Transport Layer Security (TLS) 1.2 or later. Port has a roadmap item to enforce TLS 1.3 across all HTTPS communication.
If you choose inbound connections as an alternative to the Port agent, Port routes requests to your environment through a network address translation (NAT) gateway. These one-way requests originate from a fixed set of static IP addresses:
| Static outbound IP addresses |
|---|
44.221.30.248 |
44.193.148.179 |
34.197.132.205 |
3.251.12.205 |
34.252.219.131 |
54.75.236.107 |
Integration deployment options
Git provider applications
Port provides native GitHub and Bitbucket apps to ingest information and keep your catalog up to date. These apps use OAuth 2.0 for authentication and permissions to your Git provider.
During installation, the apps receive a limited set of permissions. Review the GitHub app permissions and Bitbucket app permissions. You can also limit access to selected repositories.
By default, Git integrations search only for README.md files and do not ingest other source code. You can configure the apps to ingest no source code files or to ingest additional files for your use case.
Open source integrations
Port provides customizable, open source integrations, including the Kubernetes exporter and Port agent. You can inspect their source code on GitHub and deploy them on your premises without opening inbound connectivity or sharing secrets or credentials with Port.
Ocean framework integrations
Port develops and maintains Ocean, an open source framework for building Port integrations. The framework and all first-party integrations are open source. You can develop integrations for internal use or contribute them to Ocean.
Ocean integrations use container images and support any containerized runtime, including deployment on your premises or within your continuous integration and continuous delivery (CI/CD) process.
When you run an Ocean integration on your premises, it acts as a proxy between Port and your environment. It manages encrypted outbound connections, controls Port's access to your data, and keeps sensitive credentials behind your firewall. You do not need to open inbound connectivity or share secrets or credentials with Port.
The integration queries your internal resource or third-party service, then parses and transforms the data according to your configuration. Processing takes place on your premises, and Port receives only the resulting entries. Ocean also includes personally identifiable information (PII) and secret-key scrubbing and masking capabilities to help prevent confidential information from leaving your premises.
Port-hosted integrations
For some third-party services, you can choose a Port-hosted integration. Port hosts, manages, and maintains it on its infrastructure, so you do not need to operate it yourself.
This option requires an access token for the third-party service and provides the same security and customization capabilities as other Ocean integrations. The integration calls the service, receives its data, processes it according to your configuration, and sends the processed results to Port.
Processing takes place outside your premises. The integration remains separate from Port itself, providing an additional layer of protection that prevents completely unprocessed data from reaching your Port account.