Diagram: Trust model
Diagram: Trust model
sts:AssumeRoleWithWebIdentity + External IDOIDC trust to PANW IdP.
Per-call session token.
Workload Identity Federation to customer-owned service account. No static SA key.
Per-call token.
### **General architecture**
Cortex Cloud Outpost scanning involves three distinct areas:
* **Monitored accounts:** Your cloud accounts that hold the workloads being scanned. Disk snapshots are created here and shared with a separate scanning environment; the raw data stays within your cloud.
* **Outpost:** A dedicated, single-tenant scanning environment in the same cloud provider and region as the monitored account. In outpost scan mode this is an account you own and operate.
* **Cortex Cloud:** The Palo Alto Networks-operated platform, running in a single Cortex region, that orchestrates scans and receives only metadata and findings.
### **Artifact bucket or Blob container**
In some scanning use cases, the cloud provider does not support exposing a copy of your data to be shared across account boundaries via a control plane API. For instance, to get read access to a database running in a monitored account, while accessing it from an outpost, we need to export the database content to a file, make that file available to the outpost, and pull it down to a scanner to be analyzed.
For those use cases, we have a second regional container called an “artifact bucket” (or Blob container) that contains your data. Objects that are uploaded to this bucket are [encrypted at rest and in transit](#data-encryption-at-rest-and-in-transit), and they are deleted as soon as the analysis of the data is completed. Some of the data operations are triggered from Cortex Cloud, however it doesn’t have any read permissions on that bucket. Only the scanner VM IAM roles have read permissions on this bucket.
Different methods are used to prepare the data for analysis, depending on the database's architecture. In some cases, a direct export is required, while in others, a snapshot is created and queried. The results of these scans are then stored in the artifact bucket for the outpost to process. You can learn more about these methods for preparing the data for analysis in the [Data Security Posture Management (DSPM)](/cortex-cloud-outposts/scanners.md#data-security-posture-management-dspm) flow below.
### **Scanner access to cloud resources**
Scanner VMs have a workload identity component, using an instance profile, or similar, to assign the VMs specific permissions. These permissions allow the scanner to access cloud services, usually running in monitored accounts, via private endpoints. One of the roles in the monitored account establishes this trust relationship in the Scanner IAM role. These trust relationships ensure the scanner can securely access the relevant assets for all supported domains, including disk snapshots for vulnerability and misconfiguration checks, container images for registry scans, serverless functions for code review, and object storage for data classification.
The outpost spins up these VMs as scanners when needed from the same hardened image. However, each scanner has its own dedicated purpose, its own set of permissions, and its own network access; some are for registry scanning, some are for disk scanning, and so on. So, for example, registry scanners do not have access to disk volumes.
In addition to disk analysis for Cloud Workload Protection (CWP), the outpost uses these ephemeral VMs to scan jobs for other services:
* For Agentless Disk Scanning (ADS), the VM accesses securely shared snapshot volumes from the monitored account.
* For Registry Scanning, the VM securely pulls container images from the monitored repository.
* For Serverless Scanning, the VM retrieves and analyzes serverless function code and configurations.
* For Data Security Posture Management (DSPM), the VM processes data copies and exports from cloud storage services to perform classification.
The termination of the VM after job completion applies universally to all these scanning operations. When scanning and analysis are complete, the scanner VM is deleted to maintain a clean security posture.
Scanner VMs are spun up at runtime using a dynamic selection strategy to determine VM family, type, and size based on the needs of the scanner.
Cortex attempts to use spot instances where available for additional savings. The system also queries for spot eviction history rates to aid in dynamically selecting the best VM size. For example, Cortex attempts to use spot instances where available for additional savings. The system also queries for spot eviction history rates to aid in dynamically selecting the best VM size.
The scanner orchestration takes into account the expected runtime of the scan and cloud economics. For example:
* DSPM scans usually run for several hours so they are scheduled on “on demand” instances, preventing them from being interrupted.
* ADS scans attempt to leverage spot instances when available and fall back to “on demand” instances when spot capacity is insufficient.
The scaling strategy for scanner VMs is event-driven and based on creating ephemeral instances on demand, rather than using a traditional autoscaling group that maintains a persistent set of VMs. The system "scales" by creating as many individual VMs as are needed for the concurrent scanning workload, and automatically "scales down" by terminating them as soon as their work is done.
### **Data encryption at rest and in transit**
The core security and data residency principles of the outpost mode are based on:
* **Data encryption, both at rest and in transit**: Data encryption is applied uniformly across the entire scanning pipeline to protect customer data. Data at rest (such as disk snapshots and communication artifacts in the local data bucket/blob) is always secured using native cloud encryption mechanisms, at least as strongly as the original dataset. Data in transit (configuration and metadata sent to and from Cortex Cloud) is protected using TLS/HTTPS encryption (minimum TLS 1.2, TLS 1.3 preferred), ensuring secure transfer over the cloud provider's internal, non-public network path.
* **Strict regional data processing and residency**: Assets from one region are never scanned in another region; if no outpost is configured for a specific customer cloud account region, those assets are not scanned. This design, known as "regional symmetry," ensures that all scanning operations are executed within the same geographic boundaries where the customer's data resides. This local processing model is critical for compliance with strict data residency requirements (for example, GDPR, HIPAA), and it inherently minimizes unnecessary cross-region data transfer costs.
* **Limited, or no, egress and ingress:** The outpost is designed as a sealed environment that operates securely with minimal external communication. The deployment utilizes network controls (security groups, firewall rules) to strictly prohibit unsolicited inbound (ingress) traffic. Scanner VMs generally do not communicate with external services. When outbound (egress) communication is strictly necessary for specific scan types (for example, external registries or SaaS services), it is routed through a dedicated egress filter VM (proxy) with Layer 7 controls, ensuring strict allowance only to configured destinations.\
In a BYON outpost, you provide the network and control its egress path.
* **Private IPs are used, wherever possible:** Network traffic between all internal outpost components, as well as communication between the outpost and the monitored account, leverages VPC endpoints and private IPs. This design keeps traffic on the secure, private backbone of the Cloud Service Provider (CSP) network, avoiding the public Internet entirely. The use of private paths applies to all critical interactions, including access to API endpoints, container registries, and storage services.
In a BYON outpost, you create the private service connections (such as VPC endpoints, Private Service Access, or private endpoints) that scanners use to reach the CSP APIs and the outpost's storage. If these connections are not in place, traffic cannot stay on private paths and as a result scans may fail.
For more information, see [Bring Your Own Network (BYON)](#bring-your-own-network-byon).
#### **Standard data encryption flow**
This architecture illustrates the standard data flow for outpost scanning, emphasizing layered encryption and strict adherence to data residency.
1. Cortex Cloud sends configuration (policies, binaries, and so on) to the outpost by placing this data in a bucket. The “in transit” part is secure and the "at rest" part is also secured by bucket configuration.
2. This configuration data is protected by In Transit encryption, using private IPs, ensuring data travels securely over a private, non-public network path.
3. The Cloud Service Provider (CSP) APIs manage the resource creation lifecycle. The CSP APIs, which have access to both the outpost and Cortex Cloud, provision and manage the necessary VMs within the outpost. This interaction is typically authenticated and authorized with role-based access control, and is not considered external communication that requires a separate layer of encryption.
4. The outpost's VMs perform the core scanning functions. Data needed for scanning is stored in the local data bucket/blob, which is secured with At Rest encryption. This ensures that data is protected while stored on disk.
5. The outpost uses VPC endpoints to connect to the monitored account's main API endpoints, which allows the outpost to discover and enumerate target resources.\
Establishing these private connections is preferred over routing traffic through the public internet. Depending on the environment, such as in AWS, it is important to distinguish between endpoint types. Gateway endpoints should be used for object storage and DynamoDB, while interface endpoints should be used for services like STS, ECR, and Lambda.
When accessing specific data for scanning, such as container images or storage blobs, the outpost connects to the respective service endpoints (such as container registry or storage endpoints) via a private path using VPC endpoints.
6. Scan outputs (metadata only) are securely transmitted to Cortex Cloud via a private endpoint using In Transit encryption. This critical design ensures the data travels over the cloud provider's internal network, preventing any egress of customer raw data, avoiding the public Internet, and providing maximum assurance of data residency.
#### **External data encryption and networking**
{% hint style="info" %}
**Note:**\
This section describes egress and network handling for a standard outpost deployment. To customize outbound traffic using your own policies, such as your own egress inspection and logging, see [Bring Your Own Network (BYON)](#bring-your-own-network-byon).
{% endhint %}
When use cases involve external network access, such as when scanning a SaaS service or an on-prem service that you host, outbound traffic from the scanner VMs will go through first-party egress filtering.
The egress filter (represented as the Proxy VM in the diagram above) is implemented as a special VM in the outpost, and it ensures that each Scanner VM is only allowed access to specific destinations based on your configuration. For instance, if you configured a specific JFrog.io registry to be scanned, then only access to the FQDN for that service is allowed. This allows us to lock down the environment very tightly.
To enforce this strict isolation, the Scanner VMs (Local Data Processing) are deployed with a highly restrictive Security Group (SG) pattern:
* As a primary design intent—rather than an absolute constraint—inbound connections to the scanner VMs are blocked.Cortex Cloud does not require the customer to open any inbound firewall rules; all interactions are initiated from within the outpost or from the customer's CSP control-plane APIs.
* Restricted egress: Outbound traffic is limited solely to the proxy (TCP) and necessary Cloud Service Provider (CSP) endpoints over HTTPS (port 443), using TLS 1.2+. As shown in the architecture diagram above, telemetry egress routes safely through a private endpoint.
Only the egress filter is allowed access outside the virtual network. Scanner VMs only directly communicate with the egress filter to reach external destinations. The egress filter VM is only spun up when needed, and it is promptly terminated when no longer required to support scanning workloads. The egress traffic can be set up such that it uses a stable IPv4 address.
Egress always happens in the same region where the Scanner VM executes, minimizing cross-region costs and ensuring data residency requirements are met. If the scanning workload is running in several regions and requires egress, each region will have its own egress filter spun up, and its own stable IP address established, if needed.
Stable egress configuration is useful for scenarios where a customer wants to allow-list the outpost on the scanned SaaS side.
#### **Secure handling of external credentials (secrets)**
Certain scanning operations, such as those targeting non-cloud-native registries (such as JFrog Artifactory Container Registry) or third-party SaaS services (such as Snowflake), require specific authentication credentials. To securely handle these secrets, Cortex Cloud utilizes the customer-managed cloud-native secret manager service within the outpost account.
When a user provides credentials, Cortex Cloud securely transfers the secret to the outpost environment. The secret is then stored in the cloud-native secret manager (such as AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault). The outpost's role is provisioned with write permissions to store the secret, and the dedicated scanner VMs are granted strictly controlled read-only access to retrieve only the necessary credentials. By relying on the CSP's native secret manager, the credentials are protected by your existing security controls.
### **Outpost customization**
It is recommended to deploy a standard outpost in which Palo Alto Networks provides the complete infrastructure definition. The deployment creates every required resource in your dedicated outpost account, including identities, networking, storage, and compute.
Some organizations operate under governance policies that restrict who may create certain classes of resource, particularly directory-level identities and network infrastructure. For these cases, Cortex Cloud supports customization options that let you supply specific components yourself while Cortex Cloud deploys and manages the remainder.
Each customization option narrows what the outpost deployment creates in your environment. This reduces the permissions the deployment requires, and correspondingly increases the setup and lifecycle responsibilities that you retain.
Review the tradeoffs under [Determine level of customization](/cortex-cloud-outposts/outpost-planning.md#determine-level-of-customization) before selecting an option.
| **Customization option** | **What you provide** | **Supported CSPs** | **Availability** |
| --------------------------------- | ----------------------------------------------------------------- | ------------------ | ------------------------------------------------------- |
| **Standard outpost** | The account. Cortex Cloud creates all resources. | AWS, Azure, GCP | Generally available |
| **Bring Your Own App (BYOA)** | The Entra ID app registration and its optional service principal. | Azure only | Generally available |
| **Bring Your Own Network (BYON)** | The network infrastructure in which the outpost runs. | AWS, Azure, GCP | Generally available as of the Cortex Cloud 2.3 release. |
{% hint style="info" %}
**Note**:\
The customization mode is fixed at deployment, so make sure to choose the customization level before you deploy. Once an outpost is deployed, you cannot convert it between standard, BYOA, and BYON modes. To change modes you must deploy a new outpost.
{% endhint %}
#### **Bring Your Own App (BYOA)**
BYOA applies to **Azure outposts only**. It allows you to deploy a Cortex Cloud Azure outpost using an Entra ID app registration that you create and own, rather than one created by the deployment.
With BYOA, you do not need to grant the tenant-scoped Application.ReadWrite.All permission. Instead, you create the Entra ID app registration yourself, and the deployment only needs ownership of that single app registration.
For comparison, a standard Azure outpost creates the app registration and its federated identity credentials during deployment, so the Terraform runner needs Application.ReadWrite.All at the tenant level. Organizations with strict governance over Entra ID tenant-level resources often cannot grant that permission.
In a standard Azure outpost, the Terraform runner creates the app registration and its federated identity credentials in your Entra ID tenant during deployment. This requires the tenant-scoped Application.ReadWrite.All permission. Organizations with strict governance over Entra ID tenant-level resources may not be able to grant that permission.
| **Permission aspect** | **Standard Azure outpost** | **BYOA outpost** |
| ---------------------------------------------- | --------------------------------------- | ------------------------------------------- |
| Entra ID permission the Terraform runner needs | Tenant-scoped Application.Readwrite.All | Ownership of one app registration only |
| Tenant-level writes by Cortex Cloud | Creates the app registration | None beyond the app registration you supply |
With BYOA, the division of ownership changes:
* You create and own the app registration and its mandatory service principal in your Entra ID directory, before deployment begins.
* The Terraform runner holds only object-scoped ownership of that single app registration. It holds no tenant-wide permission.
* Cortex Cloud never writes to your Entra ID tenant beyond that one app registration.
The following table shows what you provide and what the outpost deployment creates.
| **You create (once)** | **Cortex Cloud creates during deployment** |
| --------------------------------------------------------------------------- | ------------------------------------------------------------- |
| The Entra ID app registration and its service principal | All federated identity credentials on your app registration |
| Ownership of the app registration, granted to the Terraform runner identity | All outpost infrastructure (storage, networking, scanner VMs) |
| Optionally, the scanner user-assigned managed identities (UAMIs) | The scanner managed identities, unless you provide your own |
{% hint style="info" %}
**Note**:\
BYOA changes only the app-registration side of the outpost. Scanning behavior, the trust model, and every other concept described in this document remain identical to a standard Azure outpost.
{% endhint %}
For more information about BYOA outposts, see [Outpost creation](/cortex-cloud-outposts/outpost-creation.md). Deploying an Azure BYOA outpost requires preparing prerequisites, registering the application, executing the deployment, and verifying the setup. To prevent common deployment failures, carefully distinguish between the permissions for the App Registration Creator and the Terraform Runner Identity. While app registration can be done manually in the Azure portal, using the provided shell script is recommended. Complete the process by creating the outpost in Cortex, running the Terraform template in Azure, and performing post-execution verification checks.
#### **Bring Your Own Network (BYON)**
BYON allows you to deploy the outpost into network infrastructure that you create, own, and manage, rather than the network the standard deployment provisions. BYON is supported on **AWS, Azure, and GCP**.
{% hint style="info" %}
**Note**:\
When you deploy a BYON outpost, you are able to control only the egress communication.
{% endhint %}
{% hint style="info" %}
**Note:**\
BYON is generally available as of the Cortex Cloud 2.3 release.
{% endhint %}
In a standard outpost, the deployment creates a dedicated network in every outpost region: a virtual network with a wide CIDR range, two subnets in separate availability zones, and the network security rules applied to scanners. This regional symmetry is created automatically, and Cortex Cloud manages it for the outpost's lifetime.
BYON inverts that ownership. You provision the virtual networks, subnets, and network security rules according to your own network standards, and you supply them to the outpost deployment. The deployment then places scanner infrastructure into the network you have designated instead of creating its own.
This suits organizations that:
* Operate a centrally governed network architecture in which CIDR allocation, subnet design, and routing are controlled by a dedicated network team.
* Enforce network policies such as egress inspection, traffic logging, and private connectivity to internal services that must apply uniformly to all workloads, including scanners.
* Are subject to audit requirements under which security scanning traffic must traverse network paths the organization operates and monitors directly.
* Require outbound (egress) scanner traffic to route through customer-managed firewalls, proxies, and inspection tools when accessing non-cloud-native or external resources.
* Do not require direct management of private endpoints, recognizing that Cortex Cloud continues to provision and manage all required private endpoints and Private Link connections rather than reusing pre-existing ones in your network.
Under BYON, the boundary of responsibility shifts:
| **Responsibility** | **Standard outpost** | **BYON outpost** |
| ------------------------------------------------------------------- | -------------------- | ---------------- |
| Virtual network and subnet creation | Cortex Cloud | You |
| CIDR planning and IP address capacity | Cortex Cloud | You |
| Network security rules applied to scanners | Cortex Cloud | You |
| Egress connectivity to Cortex Cloud and CSP APIs | Cortex Cloud | You |
| Adding network capacity in new outpost regions | Cortex Cloud | You |
| Scanner compute, storage, and identities | Cortex Cloud | Cortex Cloud |
| Scanning operations and data handling | Cortex Cloud | Cortex Cloud |
| Private endpoint creation and management (or private link creation) | Cortex Cloud | Cortex Cloud |
For more information about BYON outposts, see [Outpost creation](/cortex-cloud-outposts/outpost-creation.md).
Scanners have specific network reachability requirements. They must reach the Cortex Cloud control plane, the CSP APIs of the monitored accounts, and the outpost's own storage. A network that does not satisfy these requirements will cause scans to fail, and diagnosing those failures is a shared exercise between your network team and Palo Alto Networks. Plan for a longer deployment cycle than a standard outpost, and involve your network team from the outset.
### **Outpost versioning**
Until Cortex Cloud supports outpost versioning, when a Cortex Cloud tenant is upgraded to a new release, you are not required to immediately upgrade your outposts or monitored accounts’ connectors. System functionality should not be impacted. However, new features, capabilities and optimizations might not be available when using an outdated outpost.
When a newer cloud onboarding template exists, you will be prompted at the connector level to upgrade that connector by re-deploying with the newest template. Similarly, outposts will also require upgrades to keep functioning. (Note that currently the prompt for upgrading is only at the connector level, not at the outpost level.)
### **Outpost health**
The outpost may have health issues associated with it. The issues expose challenges that Cortex Cloud is facing when using the outpost and attempting to scan your assets within the outpost. These issues may result from, for example, insufficient permissions (such as when an SCP impacts granted permissions), misconfigured infrastructure resources, quota limits and rate limits. You are expected to monitor your environment for and fix [health issues](https://cortex-docs.paloaltonetworks.com/cortex-cloud-runtime-security/cortex-cloud-data-sources-and-connectors/administration-and-troubleshooting/about-health-issues) that are generated.
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://cortex-docs.paloaltonetworks.com/cortex-cloud-outposts/concepts.md?ask=