OpenShift
Prisma Cloud Console is deployed as a Deployment, which ensures it’s always running.
The Prisma Cloud Console and Defender container images can be stored either in the internal OpenShift registry or your own Docker v2 compliant registry.
Alternatively, you can configure your deployments to pull images from Prisma Cloud’s cloud registry.
Prisma Cloud Defenders are deployed as a DaemonSet, which ensures that an instance of Defender runs on every node in the cluster.
You can run Defenders on OpenShift master and infrastructure nodes by removing the taint from them.
The Prisma Cloud Defender container images can be stored either in the internal OpenShift registry or your own Docker v2 compliant registry.
Alternatively, you can configure your deployments to pull images from Prisma Cloud’s cloud registry.
This guide shows you how to generate deployment YAML files for both Console and Defender, and then deploy them to your OpenShift cluster with the oc client.
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.
Minimum system requirements
Validate that the components in your environment (nodes, host operating systems, orchestrator) meet the specs in
System requirements.
For OpenShift installs, we recommend using the overlay or overlay2 storage drivers due to a known issue in RHEL.
For more information, see https://bugzilla.redhat.com/show_bug.cgi?id=1518519.
Permissions
Validate that you have permission to:
- Push to a private docker registry. For most OpenShift setups, the registry runs inside the cluster as a service. You must be able to authenticate with your registry with docker login.
- Pull images from your registry. This might require the creation of a docker-registry secret.
- Have the correct role bindings to pull and push to the registry. For more information, see Accessing the Registry.
- Create and delete projects in your cluster. For OpenShift installations, a project is created when you run oc new-project.
- Run oc create commands.
Internal cluster network communication
TCP: 8083, 8084
External cluster network communication
TCP: 443
The Prisma Cloud Console connects to the Prisma Cloud Intelligence Stream (https://intelligence.twistlock.com) on TCP port 443 for vulnerability updates.
If your Console is unable to contact the Prisma Cloud Intelligence Stream, follow the guidance for offline environments.
Install Prisma Cloud
Download the Prisma Cloud software
Download the latest Prisma Cloud release to any system where the OpenShift oc client is installed.
- Go to Releases, and copy the link to current recommended release.
- Download the release tarball to your cluster controller.$ wget <LINK_TO_CURRENT_RECOMMENDED_RELEASE_LINK>Unpack the release tarball.$ mkdir twistlock $ tar xvzf twistlock_<VERSION>.tar.gz -C twistlock/
- Login to the OpenShift cluster and create the twistlock project:$ oc new-project twistlock
- OpenShift internal registry.
- Private Docker v2 registry. You must create a docker-secret to authenticate with the registry.
- Determine the endpoint for your OpenShift internal registry. Use either the internal registry’s service name or cluster IP.$ oc get svc -n default NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE docker-registry ClusterIP 172.30.163.181 <none> 5000/TCP 88dPull the images from the Prisma Cloud cloud registry using your access token. The major, minor, and patch numerals in the <VERSION> string are separated with an underscore. For exampe, 18.11.128 would be 18_11_128.$ docker pull \ registry-auth.twistlock.com/tw_<ACCESS_TOKEN>/twistlock/defender:defender_<VERSION> $ docker pull \ registry-auth.twistlock.com/tw_<ACCESS_TOKEN>/twistlock/console:console_<VERSION>Tag the images for the OpenShift internal registry.$ docker tag \ registry-auth.twistlock.com/tw_<ACCESS_TOKEN>/twistlock/defender:defender_<VERSION> \ 172.30.163.181:5000/twistlock/private:defender_<VERSION> $ docker tag \ registry-auth.twistlock.com/tw_<ACCESS_TOKEN>/twistlock/console:console_<VERSION> \ 172.30.163.181:5000/twistlock/private:console_<VERSION>Push the images to the twistlock project’s imageStream.$ docker push 172.30.163.181:5000/twistlock/private:defender_<VERSION> $ docker push 172.30.163.181:5000/twistlock/private:console_<VERSION>Install ConsoleYou can optionally customize twistlock.cfg to enable additional features. Then run twistcli from the root of the extracted release tarball.Prisma Cloud Console uses a PersistentVolumeClaim to store data. There are two ways to provision storage for Console:
- Dynamic provisioning:Allocate storage for Console on-demand at deployment time. When generating the Console deployment YAML files or helm chart with twistcli, specify the name of the storage class with the --storage-class flag. Most customers use dynamic provisioning.
- Manual provisioning:Pre-provision a persistent volume for Console, then specify its label when generating the Console deployment YAML files. OpenShift uses NFS mounts for the backend infrastructure components (e.g. registry, logging, etc.). The NFS server is typically one of the master nodes. Guidance for creating an NFS backed PersistentVolume can be found here. Also see Appendix: NFS PersistentVolume example.
Create an OpenShift project for Prisma Cloud
Create a project named twistlock.
(Optional) Push the Prisma Cloud images to a private registry
When Prisma Cloud is deployed to your cluster, the images are retrieved from a registry.
You have a number of options for storing the Prisma Cloud Console and Defender images:
Alternatively, you can pull the images from the Prisma Cloud cloud registry at deployment time.
Your cluster nodes must be able to connect to the Prisma Cloud cloud registry (registry-auth.twistlock.com) with TLS on TCP port 443.
This guides shows you how to use both the OpenShift internal registry and the Prisma Cloud cloud registry.
If you’re going to use the Prisma Cloud cloud registry, you can skip this section.
Otherwise, this procedure shows you how to pull, tag, and upload the Prisma Cloud images to the OpenShift internal registry’s twistlock imageStream.