Agentless Scanning Modes
Table of Contents
Expand all | Collapse all
-
- Getting started
- System Requirements
- Cluster Context
-
- Prisma Cloud Container Images
- Kubernetes
- Deploy the Prisma Cloud Console on Amazon ECS
- Console on Fargate
- Onebox
- Alibaba Cloud Container Service for Kubernetes (ACK)
- Azure Container Service (ACS) with Kubernetes
- Azure Kubernetes Service (AKS)
- Amazon Elastic Kubernetes Service (EKS)
- IBM Kubernetes Service (IKS)
- OpenShift v4
-
- Defender Types
- Manage your Defenders
- Redeploy Defenders
- Uninstall Defenders
-
- Deploy Orchestrator Defenders on Amazon ECS
- Automatically Install Container Defender in a Cluster
- Deploy Prisma Cloud Defender from the GCP Marketplace
- Deploy Defenders as DaemonSets
- VMware Tanzu Application Service (TAS) Defender
- Deploy Defender on Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Autopilot
- Deploy Defender on OpenShift v4
-
- Agentless Scanning Modes
-
- Onboard AWS Accounts for Agentless Scanning
- Onboard Azure Accounts for Agentless Scanning
- Configure Agentless Scanning for Azure
- Onboard GCP Accounts for Agentless Scanning
- Configure Agentless Scanning for GCP
- Onboard Oracle Cloud Infrastructure (OCI) Accounts for Agentless Scanning
- Configure Agentless Scanning for Oracle Cloud Infrastructure (OCI)
- Agentless Scanning Results
-
- Rule ordering and pattern matching
- Backup and Restore
- Custom feeds
- Configuring Prisma Cloud proxy settings
- Prisma Cloud Compute certificates
- Configure scanning
- User certificate validity period
- Enable HTTP access to Console
- Set different paths for Defender and Console (with DaemonSets)
- Authenticate to Console with Certificates
- Configure custom certs from a predefined directory
- Customize terminal output
- Collections
- Tags
- Logon settings
- Reconfigure Prisma Cloud
- Subject Alternative Names
- WildFire Settings
- Log Scrubbing
- Clustered-DB
- Permissions by feature
-
- Logging into Prisma Cloud
- Integrating with an IdP
- Integrate with Active Directory
- Integrate with OpenLDAP
- Integrate Prisma Cloud with Open ID Connect
- Integrate with Okta via SAML 2.0 federation
- Integrate Google G Suite via SAML 2.0 federation
- Integrate with Azure Active Directory via SAML 2.0 federation
- Integrate with PingFederate via SAML 2.0 federation
- Integrate with Windows Server 2016 & 2012r2 Active Directory Federation Services (ADFS) via SAML 2.0 federation
- Integrate Prisma Cloud with GitHub
- Integrate Prisma Cloud with OpenShift
- Non-default UPN suffixes
- Compute user roles
- Assign roles
-
- Prisma Cloud Vulnerability Feed
- Scanning Procedure
- Vulnerability Management Policies
- Vulnerability Scan Reports
- Scan Images for Custom Vulnerabilities
- Base images
- Vulnerability Explorer
- CVSS scoring
- CVE Viewer
-
- Configure Registry Scans
- Scan Images in Alibaba Cloud Container Registry
- Scan Images in Amazon Elastic Container Registry (ECR)
- Scan images in Azure Container Registry (ACR)
- Scan Images in Docker Registry v2 (including Docker Hub)
- Scan Images in GitLab Container Registry
- Scan images in Google Artifact Registry
- Scan Images in Google Container Registry (GCR)
- Scan Images in Harbor Registry
- Scan Images in IBM Cloud Container Registry
- Scan Images in JFrog Artifactory Docker Registry
- Scan Images in Sonatype Nexus Registry
- Scan images in OpenShift integrated Docker registry
- Scan Images in CoreOS Quay Registry
- Trigger Registry Scans with Webhooks
- Configure VM image scanning
- Configure code repository scanning
- Malware scanning
- Windows container image scanning
- Serverless Functions Scanning
- VMware Tanzu Blobstore Scanning
- Scan App-Embedded workloads
- Troubleshoot Vulnerability Detection
-
- Compliance Explorer
- Enforce compliance checks
- CIS Benchmarks
- Prisma Cloud Labs compliance checks
- Serverless functions compliance checks
- Windows compliance checks
- DISA STIG compliance checks
- Custom compliance checks
- Trusted images
- Host scanning
- VM image scanning
- App-Embedded scanning
- Detect secrets
- OSS license management
-
- Alert Mechanism
- AWS Security Hub
- Cortex XDR alerts
- Cortex XSOAR alerts
- Email alerts
- Google Cloud Pub/Sub
- Google Cloud Security Command Center
- IBM Cloud Security Advisor
- JIRA Alerts
- PagerDuty alerts
- ServiceNow alerts for Security Incident Response
- ServiceNow alerts for Vulnerability Response
- Slack Alerts
- Splunk Alerts
- Webhook alerts
- API
Agentless Scanning Modes
There are two ways you can set up agentless scanning with Prisma Cloud.
- Same account mode (Default): scans all hosts of a cloud account within the same cloud account.
- Hub account mode: a centralized account, called thehub account, scans hosts in other cloud accounts, calledtarget accounts.
Hub account mode is only supported for AWS and GCP.
Same Account Mode
In the same account mode, all of the agentless scanning process takes place within the same account.
All snapshots, scanner instances, and network infrastructure are set up within every region that has workloads deployed to it.
The same account mode is the default agentless scanning mode when onboarding cloud accounts to Prisma Cloud.
The following diagram gives a high level view of agentless scanning in same account mode:

Hub Account Mode
In hub account mode, most of the agentless scanning process takes place in a centralized account known as the hub account.
You should dedicate this account entirely to the agentless scanning process.
Each account that the hub account should scan is called a target account.
There is no limit to the number of hub accounts that you can configure and you can use each hub account to scan a different subset of target accounts.
In this mode, the scanner instances and networking infrastructure are created only on the hub account.
You don’t have to replicate the agentless scanning configuration across target accounts since you can configure agentless scanning centrally on the hub account configuration.
For example, you don’t need to replicate networking configuration across target accounts if you configured your networking infrastructure in the hub account.
- In AWS, snapshots are created within every target account and are then shared with the hub account.
- In GCP, snapshots are created directly within the hub account.
Scanners in the hub account scan target accounts independently. An agentless scanner in the hub account only scans snapshots from one target account and this ensures segregation between target accounts.
The following diagram gives a high level view of agentless scanning in hub account mode.

Scanning Modes Comparison
Same Account | Hub Account | |
---|---|---|
Permissions | All read and write permissions are required on the same account. | Most of the write permissions are required only on the hub account, and target accounts require mostly read permissions.
Because of this, this mode provides a better way to segregate permissions. |
Networking | Networking infrastructure is required on every account.
If you use custom network resources, you need to create the networking infrastructure in every region in every account. | Networking infrastructure is only required on the hub account.
If you use custom network resources, you only need to create the networking infrastructure in all regions of the hub account. |
CSP Costs Incurred by Agentless Scanning | Each cloud account is billed for the CSP costs incurred by agentless scanning. | The hub account is billed for the majority of the CSP costs incurred by agentless scanning.
You can still correlate the costs each target account incurs using CSPs costs analysis along with custom tags on the agentless scanning resources. |
Onboarding and Configuration | No additional configuration required.
This is the default mode to help you get started as soon as you complete onboarding. | Additional configuration required for each account after you complete onboarding your accounts. |