Support lifecycle
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
Support lifecycle
Because the container ecosystem is rapidly evolving, understanding supportability policies is an important part of keeping your environment supportable and secure.
This article describes not only the support policy for Prisma Cloud itself but also for other software you may integrate it with.
You can always find the most up-to-date information on available releases on the Releases page.
Definitions
- Major Releases (X.yy.zzz)--A major release includes significant new features and changes and is typically released approximately every four months. It includes all applicable fixes made in previous releases.
- Maintenance Releases (x.YY.zzz)--A maintenance release includes features, enhancements, and additional fixes; it is smaller in scale than a major release and incorporates all the applicable fixes made in previous maintenance releases.
The numbering format of numbers starts with 00 (major release), 01 (minor 1), and 02 (minor 2). For example, Maxwell’s major release is 30.00.build, the next maintenance release will be 30.01.build, and maintenance update 2 will be 30.02.build.
- End of Life (EOL)--Versions that are no longer supported by Prisma Cloud. Updating to a later version is recommended.
- Support--Includes not only resolution of technical issues through interactive assistance, but also fixes delivered in maintenance releases to correct problems.
Prisma Cloud supported versions policy
Prisma Cloud has an 'n-2' support policy, which means the current release ('n') and the previous two releases ('n-1' and 'n-2') receive support.
Note that in some cases, the resolution of a problem in the n-1 or n-2 version may require upgrading to a current build.
Prisma Cloud will make commercially reasonable efforts to work with customers that require porting fixes back to the n-1 or n-2 versions, but sometimes architectural changes are significant enough between versions that this is practically impossible without making the n-1 or n-2 versions essentially the same as the n version.
There will be version-specific API endpoints. With API versioning, as your Console is upgraded to newer versions, you can continue to use older versioned APIs with stability and migrate to newer version APIs at your convenience within the n-2 support lifecycle.
As a best practice, update your scripts to use the version-specific API endpoints to ensure that your implementation is fully supported. For the version-specific APIs, you will have access to the API Reference and Release Notes documentation for changes or updates that may impact you.
Third-party software
Customers use a diverse set of technologies in the environments that Prisma Cloud Compute protects, including host operating systems, orchestrators, registries, and container runtimes.
As the vendors and projects responsible for these technologies evolve, newly introduced versions and deprecated older versions can impact the scope of what Prisma Cloud supports.
For example, Prisma Cloud cannot effectively support third-party software that the vendor (or project) itself no longer supports.
Conversely, as new versions of 3rd party software are released, Prisma Cloud must comprehensively test them to be able to provide official support for them.
For each major and maintenance release of Prisma Cloud Compute, we begin testing by evaluating the versions of 3rd party software we list as officially supported in our system requirements.
When new supported versions of this software are available, we perform our testing for the release using them.
For example, if Red Hat were to release a new version of OpenShift before we begin testing an upcoming Prisma Cloud release, we’ll include that new OpenShift release in our testing.
If the new version of OpenShift is released after we’ve begun our testing, we’ll instead do this validation in the subsequent Prisma Cloud release.
Depending on where we are in the development cycle, this next release may be a maintenance release or the next major release.
Typically, new 3rd party releases can be supported with no or minor changes in Prisma Cloud.
However, there may be circumstances where a new version of 3rd party software introduces significant breaking changes that require more significant work within Prisma Cloud to maintain compatibility.
In these cases, we’ll update the system requirements page to clearly note this and will communicate a roadmap for supporting this software in a later release of Prisma Cloud.
While Prisma Cloud does not actively prevent interoperability with unsupported software, with each release we evaluate the versions of software supported by vendors and projects.
As older versions are deprecated, Prisma Cloud support will similarly deprecate support for them as well.