Upgrade Defender DaemonSets
Table of Contents
Prisma Cloud Enterprise Edition
Expand all | Collapse all
-
- Getting started
- System Requirements
- Cluster Context
-
- 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
- Deploy Defender with Declarative Object Management
-
- Agentless Scanning Modes
-
- Onboard AWS Accounts for Agentless Scanning
- Configure Agentless Scanning for AWS
- 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
- Customize terminal output
- Collections
- Tags
- WildFire Settings
- Log Scrubbing
- Permissions by feature
-
- 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
- Malware Scanning
- 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
Upgrade Defender DaemonSets
Upgrade the Defender DaemonSets in your environment.
Upgrade the Defender DaemonSets with twistcli (Kubernetes)
Delete the Defender DaemonSet, then rerun the original install procedure.
Prerequisites:
You know all the parameters passed to twistcli when you initially deployed the Defender DaemonSet.
You’ll need them to recreate a working configuration file for your environment.- Delete the Defender DaemonSet.$ kubectl -n twistlock delete ds twistlock-defender-ds $ kubectl -n twistlock delete sa twistlock-service $ kubectl -n twistlock delete secret twistlock-secretsRetrive Console’s API address (PRISMA_CLOUD_COMPUTE_CONSOLE_URL).
- Sign into Prisma Cloud.
- Go toCompute > Manage > System > Utilities.
- Copy the URL underPath to Console.
Retrieve Console’s hostname (PRISMA_CLOUD_COMPUTE_HOSTNAME).The hostname can be derived from the URL by removing the protocol scheme and path. It is simply the host part of the URL. You can also retrieve the hostname directly.- Go toCompute > Manage > Defenders > Deploy > Defenders > Orchestrator
- Copy the hostname fromStep 3(The name that Defender will use to connect to this Console)
Generate a defender.yaml file, where:The following command connects to Console (specified in --address) as user <ADMIN> (specified in --user), and generates a Defender DaemonSet YAML config file according to the configuration options passed to twistcli. The --cluster-address option specifies the address Defender uses to connect to Console.$ <PLATFORM>/twistcli defender export kubernetes \ --user <ADMIN_USER> \ --address https://yourconsole.example.com:8083 \ --cluster-address twistlock-console- <PLATFORM> can be linux, osx, or windows.
- <ADMIN_USER> is the name of a Prisma Cloud user with the System Admin role.
Deploy the Defender DaemonSet.$ kubectl create -f defender.yamlIn Prisma Cloud, go toCompute > Manage > Defenders > Manage > DaemonSetsto see a list of deployed Defenders.Upgrade the Defender DaemonSets with twistcli (OpenShift)Delete the Defender DaemonSet, then rerun the original install procedure.Prerequisites:You know all the parameters passed to twistcli when you initially deployed the Defender DaemonSet. You’ll need them to recreate a working configuration file for your environment.- Delete the Defender DaemonSet.$ oc -n twistlock delete ds twistlock-defender-ds $ oc -n twistlock delete sa twistlock-service $ oc -n twistlock delete secret twistlock-secretsRetrive Console’s API address (PRISMA_CLOUD_COMPUTE_CONSOLE_URL).
- Sign into Prisma Cloud.
- Go toCompute > Manage > System > Utilities.
- Copy the URL underPath to Console.
Retrieve Console’s hostname (PRISMA_CLOUD_COMPUTE_HOSTNAME).The hostname can be derived from the URL by removing the protocol scheme and path. It is simply the host part of the URL. You can also retrieve the hostname directly.- Go toCompute > Manage > Defenders > Deploy > Defenders > Orchestrator
- Copy the hostname fromStep 3(The name that Defender will use to connect to this Console)
Generate a defender.yaml file, where:The following command connects to Console (specified in --address) as user <ADMIN> (specified in --user), and generates a Defender DaemonSet YAML config file according to the configuration options passed to twistcli. The --cluster-address option specifies the address Defender uses to connect to Console.$ <PLATFORM>/twistcli defender export openshift \ --user <ADMIN_USER> \ --address https://yourconsole.example.com:8083 \ --cluster-address twistlock-console \ --selinux-enabled- <PLATFORM> can be linux, osx, or windows.
- <ADMIN_USER> is the name of a Prisma Cloud user with the System Admin role.
Deploy the Defender DaemonSet.$ oc create -f defender.yamlIn Prisma Cloud, go toCompute > Manage > Defenders > Manage > DaemonSetsto see a list of deployed Defenders.Upgrade the Defender DaemonSets from ConsoleUpgrade the Defender DaemonSets directly from the Console UI.If you can’t access your cluster with kubectl or oc, then you can upgrade Defender DaemonSets directly from the Console UI.Prerequisites:You’ve created a xref:~/authentication/credentials-store/kubernetes-credentials.adoc[kubeconfig credential] for your cluster so that Prisma Cloud can access it to upgrade the Defender DaemonSet.- Log into Prisma Cloud Console.
- Go toManage > Defenders > Manage.
- ClickDaemonSets.
- For each cluster in the table, clickActions > Upgrade.The table shows a count of deployed Defenders and their new version number.