Configuring Prisma Cloud proxy settings
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
Configuring Prisma Cloud proxy settings
In some environments, access to the internet must go through a proxy and you can configure Prisma Cloud to route requests through your proxy.
Proxy settings can either be applied to both Console and Defender containers or separately for each Defender deployment.
The global proxy settings are configured in the UI after Console is installed.
Console starts using these settings after you apply it.
Any Defenders deployed after you configure the proxy settings will use it unless you explicitly choose a different proxy when deploying the Defenders.
Any Defenders that were deployed before you saved your proxy settings must be redeployed.
Console
Console has a number of connections that might traverse a proxy.

- Retrieving Intelligence Stream updates.
- Connecting to services, such as Slack and JIRA, to push alerts.
Defenders
Defender has a number of connections that might traverse a proxy.

- Connecting to Console.If you have a proxy or a load balancer between Defender and Console, make sure that TLS interception is not enabled. The certificate and keys used for the Console to Defender mutual TLS v1.2 web socket session cannot be intercepted. This ensures that the Console is only communicating with the Defenders it has deployed and the Defenders only communicate with the Console that manages them.
- Connecting to external systems, such as Docker Hub or Google Container Registry, for scanning.
- Connecting to your secrets store to retrieve secrets for injection into your containers.
Global proxy settings
A number of settings let you specify how Prisma Cloud interfaces with your proxy.
Proxy bypass
You can provide a list of addresses—DNS names, IP addresses, or a combination of both—that Prisma Cloud can contact directly without connecting through the proxy.
Specifying IP addresses in CIDR notation is supported. Specifying DNS names using wildcards is supported.
CA certificate
Console verifies server certificates for all TLS connections.
With TLS intercept proxies, the connection from Console to the Internet passes through a proxy, which may be transparent.
To facilitate traffic inspection, the proxy terminates the TLS connection and establishes a new connection to the final destination.
If you have a TLS intercept proxy, it will break the Console’s ability to connect to external services, because Console won’t be able to verify the proxy’s certificate.
To get Console to trust the proxy, provide the CA certificates for Console to trust. And, ensure that your proxy uses the client certificate of the Defender when it sends requests from the Defender to the Console.
Proxy authentication
If egress connections through your proxy require authentication, you can provide the credentials in Prisma Cloud’s proxy settings.
Prisma Cloud supports Basic authentication for the Proxy-Authenticate challenge-response framework defined in RFC 7235.
When you provide a username and password, Prisma Cloud submits the credentials in the request’s Proxy-Authorization header.
Configuring global proxy settings
Configure your proxy settings in Console.
- Open Console, and go toManage > System > Proxy.
- InHTTP Proxy, enter the address of the web proxy. Specify the address in the following format: <PROTOCOL>://<IP_ADDR|DNS_NAME>:<PORT>, such as http://proxyserver.company.com:8080.
- (Optional) InNo Proxy, enter addresses that Prisma Cloud can access directly without connecting to the proxy. Enter a list of IP addresses and domain names. Specifying IP addresses in CIDR notation is supported. Specifying DNS names using wildcards is supported.
- (Required for TLS intercept proxies only) Enable trusted communication to the Prisma Cloud Console.The proxy must trust the Prisma Cloud Console Certificate Authority (CA) and use the client certificate of the Defender when the proxy sends requests from the Defender to the console.
- Enter the proxy root CA, in PEM format that Console should trust.
- Configure the proxy to use the Defender client-certificate when it opens a TLS connection to the Console.Use the/api/v1/certs/server-certs.shAPI to obtain the following files:
- The client key of the Defender:defender-client-key.pem
- The client certificate of the Defender:defender-client-cert.pem
- The Prisma Cloud Console CA certificate:ca.pem
- (Optional) If your proxy requires authentication, enter a username and password.
- ClickSave.
- Redeploy your Defenders to propagate updated proxy settings to them.Console does not need to be restarted. After proxy settings are saved, Console automatically uses the settings the next time it establishes a connection.Any newly deployed Defenders will use your proxy settings.Any already deployed Defenders must be redeployed. For single Container Defenders, uninstall then reinstall. For Defender DaemonSets, regenerate the DaemonSet YAML, then redeploy.$ kubectl apply -f defender.yaml
Configuring per-deployment proxy settings
Prisma Cloud supports setting custom proxy settings for each Defender deployment. This way you can set multiple proxies for Defenders which are deployed in different environments.
- Open Console, and go toManage > Defenders > Deploy.
- Choose your preferred deployment method.
- Click onSpecify a proxy for the defender (optional)and enter your proxy details.