> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-cloud-outposts/scanners.md). # Scanners This section highlights a few use cases that demonstrate how Cortex incorporates the above-mentioned concepts while implementing active disk scanning, data security posture management, and image registry scanning on outposts. ### **Agentless Disk Scanning (ADS)** Cortex Cloud's Agentless Disk Scan is designed to identify vulnerabilities, malware, misconfigurations, and secrets within your cloud workload without requiring agents to be installed on your cloud instances. ADS allows the system to analyze data without affecting the performance or integrity of the live workload. All interactions between outposts and Cortex Cloud use bucket-based communications. This process relies on snapshots and controlled use of encryption keys. Diagram: Agentless disk scanning (Azure example) Diagram: Agentless disk scanning with encryption (AWS example) ADS includes VM snapshot scanning and VM image scanning. #### **Snapshot scanning** This overview describes how snapshot instances are scanned, including how Cortex safeguards the security of your data: 1. **Creating snapshots**. The snapshots are stored in your environment, and are accessed using secure key handling. When the original disk/volume in your monitored environment is secured with your own customer-managed encryption key (CMK/CMEK), Cortex Cloud performs a highly secure, non-intrusive re-encryption process.
Cortex Cloud does not create new keys in your monitored account, nor does it access or operate your key management service (KMS) or key vault. The cortex platform role only has read permissions to retrieve your key ID and metadata. This is solely for the purposes of understanding the encryption context and preparing for subsequent decryption operations. The actual key material is never exposed or moved. Additionally, KMS permissions are scoped to to allow only from specific services.
Data remains encrypted at all times. The snapshot's encryption key is securely re-encrypted with a Palo Alto Networks-owned key (key-wrapping operation). This process, managed by the CSP’s control plane, ensures that the raw data in the snapshot remains encrypted at rest and is never transferred in an unencrypted state.
In summary, if the managed disk has encryption enabled, Cortex Cloud needs access to the key vault keys to: * Get the encryption key metadata. * Reencrypt using a Cortex Cloud key. * Understand the encryption context and prepare for subsequent decryption operations. * Identify invalid key states like deleted or disabled, where such volumes can’t be scanned and will be reported via the console’s health monitoring UI. 2. **Handling and scanning snapshots**. The encrypted snapshots are accessed by the outpost account. The outpost accesses the snapshots and creates encrypted disks that are scanned by ephemeral VMs. Encryption is handled differently depending on the cloud provider. For example, encryption might be handled with the default keys of the provider. 3. **Cleanup**. Only the metadata scan results are displayed in your Cortex Cloud console for review and action. Temporary scanner instances, attached disks, and copied snapshots in the outpost are automatically and immediately deleted. Additionally, any temporary snapshots or data copies created in the monitored account for the purpose of scanning are automatically deleted by the outpost when the scanner VMs start. #### **VM image scanning** This overview describes how images in your account are prepared for scanning on the outpost. 1. **Disk/volume creation.** An API is called in your account, specifying the image type—such as Amazon Machine Image (AMI) for AWS. The API creates a disk/volume based on the image.
EntityCSPTerm
APIAWSCreateVolume
GCPCreateDisk
AzureCreateDisk
Created entityAWSEBS volume
GCPPersistent disk
AzureDisk
2. **Snapshot creation**. A snapshot is then created in your account from the disk/volume. The original snapshot remains within your boundaries at all times and is not copied to the outpost.
EntityCSPTerm
SnapshotAWSEBS snapshot
GCPDisk snapshot
AzureSnapshot
3. **Cleanup.** The disk/volume is deleted immediately after snapshot creation. 4. **Scanning**. Now a snapshot exists for the outpost to access. The scanning occurs on the outpost. ### **Registry scanning** Cortex’s registry scanner scans images by downloading them from the container registry into the outpost account (similar to a Docker pull operation). The process then extracts metadata per image, and shares it back to Cortex Cloud for evaluation. #### Registries for scanning Scanning supports the following types of registries: * **Cloud-native container registries** are container registries offered and run by cloud providers. * **External registries** consist of SaaS or any other self-hosted registry application, such as: * SaaS: Examples include GitLab and Docker Hub () * Software implementations of a registry, typically running in the client’s premises, or running on a set of Cloud VMs. Examples include Harbor, [Docker’s Registry](https://hub.docker.com/%5F/registry), and any application that implements the DockerV2 protocol. Both types of unmanaged registries can be scanned using the outpost account, but there are some differences when compared with managed registries. | **Capability** | **Cloud-native registries** | **External registries** | | --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Outpost type | Images are only pulled from the cloud provider into an outpost of the same type. For example, Azure’s ACR on a monitored account may only be scanned by an Azure outpost. | Not restricted. | | Scanning region | As with most outpost scanning operations, image files never “travel” between regions. For example, if images originated in an ACR account in US-East-1, they will be pulled into an outpost’s US-East-1 region. Moreover, where possible, Cortex uses private endpoints to ensure that traffic does not go over the internet. |

Cortex lets you decide which outpost and at which region to scan the images.For example, a Docker Hub repository can be scanned using any of the existing outposts types (Azure, AWS, and so on), and on any region, based on your preferences.

Tip:
Optimize costs by choosing a region that’s nearest to the origin registry.

| | Authentication | Managed registries use cloud permissions to enable accessing the images (as explained in detail below). | Typically you, as the customer, are expected to provide the credentials (username/password or token) during setup. For details on how these sensitive credentials are securely stored and accessed, see [Secure Handling of External Credentials (Secrets)](/cortex-cloud-outposts/concepts.md#secure-handling-of-external-credentials-secrets). | | Image discovery | Changes to images and repositories are detected during Cloud Discovery, based on resource enumeration via APIs, or on cloud audit logs (assuming such log ingestion is enabled during account onboarding). Relatively soon after new images are detected, they are dispatched by scanners. | The image discovery process itself takes place in the outpost, and would typically be slower to detect changes. Cortex does not perform discovery at a high frequency, since that would result in a heightened compute consumption and a larger cloud bill. | #### How scanning works in cloud-native registries Cortex employs several mechanisms for scanning images stored in cloud-native registries. {% hint style="info" %} **Note**:\ This section does not include information about image discovery, as this is not performed by the scanner. {% endhint %} One important mechanism is called impersonation. (See [Trust model](/cortex-cloud-outposts/concepts.md#trust-model) above for more details.) Cortex temporarily assumes the identity of a predefined role on the monitored account. Once that role is assumed, images are downloaded onto the outpost and metadata is extracted from these images. #### Process overview | **When…** | **What…** | | ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The outpost is created | A scanning Role/Service-Account entity is created on the outpost. | | The monitored account is connected to Cortex Cloud | A set of minimal permissions are defined on a dedicated role on the monitored account: Read-only access to the images. These typically include permissions to log in into the registry and to download images.The permission needed to impersonate this role from the outpost.The monitored account is configured to only grant these permissions to the Role/Service-Account when the outpost was created. | | Images are discovered as part of the discovery process (and not the scanning process) | Cortex Cloud scans the images in batches. For each batch, Cortex sets up a dedicated and ephemeral virtual machine on the outpost.The outpost’s role assumes (impersonates) the role on the monitored account. The outpost’s role logs in to the relevant registry, scans the images, and sends the metadata back through the [Communication Buckets (and Blob Containers)](/cortex-cloud-outposts/concepts.md#communication-buckets-and-blob-containers). | When scanning container images, the scanner is provisioned with a larger disk so pulling images does not saturate the free disk space. ### **Data Security Posture Management (DSPM)** On an outpost, Cortex handles DSPM by performing its security-related data analysis and remediation in your private on-premises or localized cloud environment. Sensitive data is discovered, prepared for classification, classified, and secured while ensuring that the data never leaves its designated region. This addresses strict data residency and compliance requirements. The outpost must be granted permissions to interact directly with your workloads and data. {% hint style="info" %} **Note**:\ Currently only cloud-native services are supported for outpost scan. Scanning on SaaS services, such as Snowflake and Office 365, is only supported for cloud scan. {% endhint %} Data Security Posture Management (DSPM) This flow highlights how data is scanned, including how Cortex safeguards the security of your data. 1. **Discovery and data extraction**. During regular scanning, Cortex uses the read-only permissions to discover data stores **A**, such as block storage or object storage, within your monitored account. Additionally, wherever possible, instead of scanning the live data in your account, Cortex either creates a snapshot of, or exports, data by employing different methods based on the data source: * **Storage data sources** **B:** The scanner VM directly accesses and lists files from the object storage in JSON format without creating additional resources. * **Database data sources** **C:** * **Native export:** For some managed relational databases (such as RDS/Aurora, Redshift), the outpost uses native CSP APIs to export database content directly to a file. * **Direct scan from snapshot:** For other databases (such as SQL Server, Cloud SQL), the outpost creates a snapshot of the database and performs SQL queries on the snapshot. * **Direct scan:** For specific NoSQL databases (such as DynamoDB, CosmosDB), Cortex performs SQL queries directly on the live database. The results of the queries are stored as parquet files. Your actual data is stored on the outpost during the scan operation. For all three database-based data sources, the resulting files are stored in the [artifact bucket](/cortex-cloud-outposts/concepts.md#artifact-bucket-or-blob-container) **D** on the outpost. For storage-based data sources **E**, the query results bypass the outpost artifact bucket on their way to being processed by the scanner VMs. 2. **Analysis and classification**. The outpost creates temporary scanner VMs **F** and attaches a copy of the volume snapshot to them. Scanning is performed in the same region as your data for compliance with regulations such as GDPR, HIPAA, and so on. The classification VM **G** analyzes the data to identify and classify it. This classification process uses machine learning and predefined rules to find sensitive information such as personally identifiable information (PII), intellectual property, or financial data. The scanner VM directly accesses and lists files from the object storage in JSON format without creating additional resources. Upon completion, the metadata results are uploaded to the communication bucket/blob for full auditability of the scanned data.\ Only metadata is sent to Cortex Cloud for remediation. 3. **Cleanup**. After the security task is complete, the outpost maintains a clean security posture. It uses its delete permissions to remove all temporary resources it created during the process, including the VMs, disks created from snapshots, and any unused network components. This ensures that no unnecessary resources are left behind to become future security risks. --- # 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/scanners.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.