Kubernetes
This procedure is optimized to get Prisma Cloud installed in your Kubernetes cluster quickly.
There are many ways to install Prisma Cloud, but we recommend that you start with this procedure first.
You can tweak the install procedure after you have validated that this install method works.
Prisma Cloud is installed with a utility called twistcli, which is bundled along with the rest of the Prisma Cloud software.
The twistcli utility generates YAML configuration files for Console and Defender.
You then create the required objects in your cluster with kubectl create.
This two step approach gives you full control over the objects created.
You can inspect, customize, and manage the YAML configuration files in source control before deploying Console and Defender.
Prisma Cloud Console is created as a Deployment, which ensures a single copy of Console is always up and available.
Prisma Cloud Defenders are deployed as a DaemonSet, which guarantees an instance of Defender runs on each worker node in the cluster.
In order to improve the availability of the Console service, the orchestrator should be free to run Console on any healthy node.
If a node were to go down, the orchestrator should be able to simply reschedule Console somewhere else.
To enable this capability, Console’s default YAML configuration files:
- Deploy a persistent volume (PV), where Console can save its state.No matter where Console runs, it must have access to its state. In order for PVs to work, every node in the cluster must have access to shared storage. Depending on your cloud provider, and whether Kubernetes is managed or unmanaged, setting up storage can range from easy to difficult. Google Cloud Kubernetes Engine (GKE), for example, offers it as an out-of-the box capability, so it requires zero configuration. If you build your cluster by hand, however, you might need to configure something like NFS.
- Expose Console to the network using a load balancer.Console must always be accessible. It serves a web interface, and it communicates policy with all deployed Defenders. A load balancer ensures that Console is reachable no matter where it runs in the cluster.
Cluster context
Prisma Cloud can segment your environment by cluster.
For example, you might have three clusters: test, staging, and production.
The cluster pivot in Prisma Cloud lets you inspect resources and administer security policy on a per-cluster basis.
Cluster awareness across the product
Radar lets you explore your environment cluster-by-cluster. Various scan reports and audits include the relevant cluster name to provide environment context.
You can also create stored filters (also known as collections) based on cluster names.
Finally, you can scope policy by cluster.
Vulnerability and compliance rules for container images and hosts, runtime rules for container images, and trusted images rules can all be scoped by cluster name.
Determine cluster name
Defenders in each DaemonSet are responsible for reporting which resources belong to which cluster.
When deploying a Defender DaemonSet, Prisma Cloud tries to determine the cluster name through introspection.
First, it tries to retrieve the cluster name from the cloud provider.
As a fallback, it tries to retrieve the name from the kubeconfig file (the cluster name will be taked from the server field).
Finally, you can override these mechanisms by manually specifying a cluster name when deploying your Defender DaemonSet.
Both the Prisma Cloud UI and twistcli tool accept an option for manually specifying a cluster name.
Let Prisma Cloud automatically detect the name for provider-managed clusters.
Manually specify names for self-managed clusters, such as those built with kops.
There are some things to consider when manually naming clusters:
- If you specify the same name for two or more clusters, they’re treated as a single cluster.
- For GCP, if you have clusters with the same name in different projects, they’re treated as a single cluster. Consider manually specifying a different name for each cluster.
- Manually specifying names isn’t supported inManage > Defenders > Manage > DaemonSet. This page lets you deploy and manage DaemonSets directly from the Prisma Cloud UI. For this deployment flow, cluster names are retrieved from the cloud provider or the supplied kubeconfig only.
If you wish to change the cluster name determined by Prisma Cloud Compute, or the name you manually set for the cluster, you must redeploy the Defenders DaemonSet and specify the new name. Notice that after changing the name, historical records for audits and incidents, will keep the cluster name from their creation time. The new cluster name will only apply for future records. Also, if you already created collections using the old cluster name, these need to be manually updated with the new name.
Preflight checklist
To ensure that your installation goes smoothly, work through the following checklist and validate that all requirements are met.
General
- You have a valid Prisma Cloud license key and access token.
Cluster
- You have provisioned a Kubernetes cluster that meets the minimum system requirements and runs a supported Kubernetes version.
- You have set up a Linux or macOS system as your cluster controller, and you can access the cluster with kubectl.
- The nodes in your cluster can reach Prisma Cloud’s cloud registry (registry-auth.twistlock.com).
- Your cluster can create PersistentVolumes and LoadBalancers from YAML configuration files.
Runtimes
- Prisma Cloud supports Docker Engine, CRI-O, and cri-containerd. For more information, see the system requirements
Permissions
- You can create and delete namespaces in your cluster.
- You can run kubectl create commands.
Firewalls and ports
Validate that the following ports are open.
Prisma Cloud Console
:- Incoming: 8083, 8084
- Outgoing: 443, 53
Prisma Cloud Defenders
:- Incoming: None
- Outgoing: 8084
Install Prisma Cloud
If you’re installing Prisma Cloud on Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), or Azure Container Service with Kubernetes, a number of tweaks are required to the installation procedure.
For more details, see the relevant sections in this article.
Download the Prisma Cloud software
Download the Prisma Cloud software to any system where you run kubectl to administer your cluster.
- Download the current recommended release.
- Unpack the release tarball.$ mkdir prisma_cloud $ tar xvzf prisma_cloud_compute_edition_<VERSION>.tar.gz -C prisma_cloud/
Install Console
Install Console, exposing the service using a load balancer.
apiVersion: v1 kind: PersistentVolume metadata: name: twistlock-console labels: app-volume: twistlock-console annotations: volume.beta.kubernetes.io/mount-options: "nolock,noatime,bg"
- 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 LoadBalancerDeploy Console.$ kubectl create -f twistlock_console.yamlWait for the service to come up completely.$ kubectl get service -w -n twistlockConfigure ConsoleCreate your first admin user and enter your license key.
- Get the public endpoint address for Console.