Table of Contents
Self.Hosted 31.xx
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
Kubernetes
This topic helps you install Prisma Cloud in your Kubernetes cluster quickly.
There are many ways to install Prisma Cloud, but use this workflow to quickly deploy Defenders and verify how information is accessible from the Prisma Cloud Console.
After completing this procedure, you can modify the installation to match your needs.
To install Prisma Cloud, you use the command-line utility called twistcli, which is bundled with the Prisma Cloud software.
The process has the following steps to give you full control over the created objects.
- The twistcli command-line utility generates YAML configuration files or Helm charts for the Prisma Cloud Console and Defender.
- You create the required objects in your cluster with the kubectl create command.
To better understand clusters, read our cluster context topic.
You can inspect, customize, and manage the YAML configuration files or Helm charts before deploying the Prisma Cloud Console and Defender.
You can place the files or charts under source control to track changes, to integrate them with Continuous Integration and Continuous Development (CI/CD) pipelines, and to enable effective collaboration.
To ensure a single copy of the Prisma Cloud Console is always available, the Prisma Cloud Console is created as a Kubernetes Deployment.
Kubernetes deployments are also known as Kubernetes services.
To ensure that a Prisma Cloud Defender instance runs on each worker node of your cluster, each Prisma Cloud Defender is deployed as a Kubernetes DaemonSet.
When a node goes down, the orchestrator can reschedule the Prisma Cloud Console on a different healthy node.
To improve the availability of the Prisma Cloud Console, you must ensure that the orchestrator can run the Prisma Cloud Console on any healthy node.
The default configuration files or charts ensure this capability.
These default configuration files or charts enable the following features to ensure availability.
- Deploy a persistent volume (PV), to enable Prisma Cloud Console to save the state.This configuration ensures that no matter where Prisma Cloud Console runs, it has access to the state of the deployment. For persistent volumes to work, every node in the cluster must have access to the shared storage. Setting up a persistent volume can be easy or hard depending on the following factors.
- What is your cloud provider?For example, Google Cloud Kubernetes Engine (GKE) offers persistent volumes out-of-the box with zero additional configuration required.
- Is Kubernetes managed or unmanaged?If you deploy your clusters manually, you might need to configure a Network File System (NFS).
- Expose the Prisma Cloud Console to the network through a load balancer.A load balancer ensures that the Prisma Cloud Console is reachable regardless of where it runs in the cluster. The Prisma Cloud Console must be accessible in your deployment because it serves as a web interface and communicates policy to all the deployed Defenders.
Requirements
To deploy your Defenders smoothly, you must meet the following requirements.
- You have a valid Prisma Cloud license key and access token.
- You provisioned a Kubernetes cluster that meets the minimum system requirements and runs a supported Kubernetes version.
- You set up a Linux or macOS system to control your cluster, and you can access the cluster using the kubectl command-line utility.
- The nodes in your cluster can reach Prisma Cloud’s cloud registry at registry-auth.twistlock.com.
- Your cluster can create PersistentVolumes and LoadBalancers from YAML configuration files or Helm charts.
- Your cluster uses any of the following runtimes. For more information about the runtimes that Prisma Cloud supports, see the system requirements.
- Docker Engine
- CRI-O
- CRI-containerd
Required Permissions
- You can create and delete namespaces in your cluster.
- You can run the kubectl create command.
Required Firewall and Port Configuration
Open the following ports in your firewall.
Ports for the
Prisma Cloud Console
:- Incoming: 8083, 8084
- Outgoing: 443, 53
Download the Prisma Cloud Console
Download the Prisma Cloud software to any system where you run kubectl to manage your cluster.
- Download the current release.
- Create the prisma_cloud folder and unpack the release tarball.$ mkdir prisma_cloud $ tar xvzf prisma_cloud_compute_edition_<VERSION>.tar.gz -C prisma_cloud/
Deploy the Prisma Cloud on Kubernetes
To use Prisma Cloud as part of your Kubernetes deployment, you need the twistcli command-line utility and the Prisma Cloud Defenders.
Use the twistcli command-line utility to install the Prisma Cloud Console and deploy the Defenders.
The twistcli utility is included with every release, or you can download the utility separately.
After completing this procedure, the Prisma Cloud Console and Prisma Cloud Defenders run in your Kubernetes cluster.
When you install Prisma Cloud on Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), or Alibaba Container Service with Kubernetes, additional configuration steps are required.
Install the Prisma Cloud Console and expose the service using a load balancer.
- On your cluster controller, navigate to the directory where you downloaded and extracted the Prisma Cloud release tarball.
- Generate a YAML configuration file for Console, where <PLATFORM> can be linux or osx.The following command saves twistlock_console.yaml to the current working directory. If needed, you can edit the generated YAML file to modify the default settings.$ <PLATFORM>/twistcli console export kubernetes --service-type LoadBalancerIf you’re using Network File System version 4 (NFSv4) as the persistent storage in your cluster, use the nolock, noatime and bg mount options in your PersistentVolume custom resource definition (CRD). After generating the YAML file in the Prisma Cloud Console, add the mount options to your PersistentVolume CRD as follows.apiVersion: v1 kind: PersistentVolume metadata: name: twistlock-console labels: app-volume: twistlock-console annotations: volume.beta.kubernetes.io/mount-options: "nolock,noatime,bg"Deploy the Prisma Cloud Console with the following command.$ kubectl create -f twistlock_console.yamlWait for the service to come up completely.$ kubectl get service -w -n twistlockConfigure the Prisma Cloud ConsoleCreate your first administrator and enter your license key.
- Get the public endpoint address for the Prisma Cloud Console.$ kubectl get service -o wide -n twistlockRegister a DNS entry for the external IP address of the Prisma Cloud Console. This procedure assumes the registered DNS name is yourconsole.example.com.If you need to secure the Prisma Cloud Console communication with TLS, set up a custom certificate. (Optional)Open a browser window, and navigate to the Prisma Cloud Console. By default, the Prisma Cloud Console is served with the HTTPS protocol on port 8083. You can go to https://yourconsole.example.com:8083 to access the Prisma Cloud Console.Create your first administrator.Enter your Prisma Cloud license key.The Defender communicates with the Prisma Cloud Console using TLS. Update the list of identifiers in the Prisma Cloud Console certificate that Defenders use to validate the identity of the Prisma Cloud Console.
- Go toManage > Defenders > Names.
- In theSubject Alternative Nametable, clickAdd SAN, then enter the Prisma Cloud Console IP address or domain name. Enter the yourconsole.example.com domain name. Any Defenders deployed outside the cluster can use this domain name to connect to the Prisma Cloud Console.
- In theSubject Alternative Nametable, clickAdd SANagain, then enter twistlock-console. Any Defenders deployed in the same cluster as the Prisma Cloud Console can use the yourconsole.example.com domain name to access the Prisma Cloud console.The service name of the Prisma Cloud Console is twistlock-console, but that name is not the same as the pod’s name, which is twistlock-console-XXXX.
Install Prisma Cloud with Helm chartsApply the following changes.- Pass the --helm_ option to _twistcli to generate a Helm chart. Don’t change the other options passed to twistcli since they configure the chart.
- Deploy your Defender with the helm install command instead of kubectl create.
The following procedure shows the modified commands.- Download the current recommended release.
- Create a Console Helm chart.$ <PLATFORM>/twistcli console export kubernetes \ --service-type LoadBalancer \ --helmInstall the Console.$ helm install twistlock-console \ --namespace twistlock \ --create namespace \ ./twistlock-console-helm.tar.gzCreate a Defender DaemonSet Helm chart.$ <PLATFORM>/twistcli defender export kubernetes \ --address https://yourconsole.example.com:8083 \ --helm \ --user <ADMIN_USER> \ --cluster-address twistlock-consoleInstall the Defender.$ helm install twistlock-defender-ds \ --namespace twistlock \ --create namespace \ ./twistlock-defender-helm.tar.gzTroubleshootingPod Security PolicyIf Pod Security Policy is enabled in your cluster, you might get the following error when trying to create a Defender DaemonSet.Error creating: pods "twistlock-defender-ds-" is forbidden: unable to validate against any pod security policy ..Privileged containers are not allowedIf you get this error, then you must create a PodSecurityPolicy for the Defender and the necessary ClusterRole and ClusterRoleBinding for the twistlock namespace. You can use the following Pod Security Policy, ClusterRole and ClusterRoleBinding:apiVersion: extensions/v1beta1 kind: PodSecurityPolicy metadata: name: prismacloudcompute-service spec: privileged: false seLinux: rule: RunAsAny allowedCapabilities: - AUDIT_CONTROL - NET_ADMIN - SYS_ADMIN - SYS_PTRACE - MKNOD - SETFCAP volumes: - "hostPath" - "secret" allowedHostPaths: - pathPrefix: "/etc" - pathPrefix: "/var" - pathPrefix: "/run" - pathPrefix: "/dev/log" - pathPrefix: "/" hostNetwork: true hostPID: true supplementalGroups: rule: RunAsAny runAsUser: rule: RunAsAny fsGroup: rule: RunAsAnyapiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: prismacloudcompute-defender-role rules: - apiGroups: ['policy'] resources: ['podsecuritypolicies'] verbs: ['use'] resourceNames: - prismacloudcompute-serviceapiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: prismacloudcompute-defender-rolebinding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: prismacloudcompute-defender-role subjects: - kind: ServiceAccount name: twistlock-service namespace: twistlock
Recommended For You