> For the complete documentation index, see [llms.txt](https://docs.prismacloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.prismacloud.io/admin-guide/33/install/deploy-console/console-on-openshift.md). # Deploy the Prisma Cloud Console on 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](/admin-guide/33/install/deploy-console/container-images.md). ## Preflight checklist To ensure that your installation on supported versions of OpenShift v4.x 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](/admin-guide/33/install/system-requirements.md). For OpenShift installs, we recommend using the overlay or overlay2 storage drivers due to a known issue in RHEL. For more information, see . ### 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](https://docs.openshift.com/container-platform/3.10/install_config/registry/accessing_registry.html). * 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 () 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](/admin-guide/33/tools/update-intel-stream-offline.md). ### Download the Prisma Cloud software Download the latest Prisma Cloud release to any system where the OpenShift [oc client](https://www.okd.io/download.html) is installed. 1. Go to [Releases](/admin-guide/33/welcome/releases.md), and copy the link to current recommended release. 2. Download the release tarball to your cluster controller. ``` $ wget ``` 3. Unpack the release tarball. ``` $ mkdir twistlock $ tar xvzf twistlock_.tar.gz -C twistlock/ ``` 4. Use [*twistcli*](/admin-guide/33/tools/twistcli.md) to install the Prisma Cloud Console and Defenders. The *twistcli* utility is included with every release. After completing this procedure, both Prisma Cloud Console and Prisma Cloud Defenders will be running in your OpenShift cluster. ### Create an OpenShift project for Prisma Cloud Create a project named *twistlock*. 1. Login to the OpenShift cluster and create the *twistlock* project: ``` $ oc new-project 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: * OpenShift internal registry. * Private Docker v2 registry. You must create a docker-secret to authenticate with the registry. Alternatively, you can pull the images from the [Prisma Cloud cloud registry](/admin-guide/33/install/deploy-console/container-images.md) 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. 1. 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 5000/TCP 88d ``` 2. Pull the images from the Prisma Cloud cloud registry using your access token. The major, minor, and patch numerals in the \ string are separated with an underscore. For example, 18.11.128 would be 18\_11\_128. ``` $ docker pull \ registry-auth.twistlock.com/tw_/twistlock/defender:defender_ $ docker pull \ registry-auth.twistlock.com/tw_/twistlock/console:console_ ``` 3. Tag the images for the OpenShift internal registry. ``` $ docker tag \ registry-auth.twistlock.com/tw_/twistlock/defender:defender_ \ 172.30.163.181:5000/twistlock/private:defender_ $ docker tag \ registry-auth.twistlock.com/tw_/twistlock/console:console_ \ 172.30.163.181:5000/twistlock/private:console_ ``` 4. Push the images to the *twistlock* project’s imageStream. ``` $ docker push 172.30.163.181:5000/twistlock/private:defender_ $ docker push 172.30.163.181:5000/twistlock/private:console_ ``` ### Install Console Use the *twistcli* tool to generate YAML files or a Helm chart for Prisma Cloud Compute Console. The *twistcli* tool is bundled with the release tarball. There are versions for Linux, macOS, and Windows. The *twistcli* tool generates YAML files or helm charts for a Deployment and other service configurations, such as a PersistentVolumeClaim, SecurityContextConstraints, and so on. Run the twistcli command with the *--help* flag for additional details about the command and supported flags. You 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](https://docs.openshift.com/container-platform/3.10/install_config/persistent_storage/dynamically_provisioning_pvs.html) 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](https://docs.openshift.com/container-platform/3.10/install_config/persistent_storage/persistent_storage_nfs.html#overview). Also see [Appendix: NFS PersistentVolume example](#_appendix_nfs_persistentvolume_example). #### Option #1: Deploy with YAML files Deploy Prisma Cloud Compute Console with YAML files. 1. Generate a deployment YAML file for Console. A number of command variations are provided. Use them as a basis for constructing your own working command. 1. Prisma Cloud Console + dynamically provisioned PersistentVolume + image pulled from the OpenShift internal registry.\* ``` $ /twistcli console export openshift \ --storage-class "" \ --image-name "172.30.163.181:5000/twistlock/private:console_" \ --service-type "ClusterIP" ``` 2. **Prisma Cloud Console + manually provisioned PersistentVolume + image pulled from the OpenShift internal registry.** Using the NFS backed PersistentVolume described in [Appendix: NFS PersistentVolume example](#_appendix_nfs_persistentvolume_example), pass the label to the *--persistent-volume-labels* flag to specify the PersistentVolume to which the PersistentVolumeClaim will bind. ``` $ /twistcli console export openshift \ --persistent-volume-labels "app-volume=twistlock-console" \ --image-name "172.30.163.181:5000/twistlock/private:console_" \ --service-type "ClusterIP" ``` 3. **Prisma Cloud Console + manually provisioned PersistentVolume + image pulled from the Prisma Cloud cloud registry.** If you omit the *--image-name* flag, the Prisma Cloud cloud registry is used by default, and you are prompted for your access token. ``` $ /twistcli console export openshift \ --persistent-volume-labels "app-volume=twistlock-console" \ --service-type "ClusterIP" ``` 2. Deploy Console. ``` $ oc create -f ./twistlock_console.yaml ``` You can safely ignore the error that says the twistlock project already exists. #### Option #2: Deploy with Helm chart Deploy Prisma Cloud Compute Console with a Helm chart. Prisma Cloud Console Helm charts fail to install on OpenShift 4 clusters due to a Helm bug. If you generate a Helm chart, and try to install it in an OpenShift 4 cluster, you’ll get the following error: ``` Error: unable to recognize "": no matches for kind "SecurityContextConstraints" in version "v1" ``` To work around the issue, you’ll need to manually modify the generated Helm chart. 1. Generate a deployment helm chart for Console. A number of command variations are provided. Use them as a basis for constructing your own working command. 1. **Prisma Cloud Console + dynamically provisioned PersistentVolume + image pulled from the OpenShift internal registry.** ``` $ /twistcli console export openshift \ --storage-class "" \ --image-name "172.30.163.181:5000/twistlock/private:console_" \ --service-type "ClusterIP" \ --helm ``` 2. **Prisma Cloud Console + manually provisioned PersistentVolume + image pulled from the OpenShift internal registry.** Using the NFS backed PersistentVolume described in [Appendix: NFS PersistentVolume example](#_appendix_nfs_persistentvolume_example), pass the label to the *--persistent-volume-labels* flag to specify the PersistentVolume to which the PersistentVolumeClaim will bind. ``` $ /twistcli console export openshift \ --persistent-volume-labels "app-volume=twistlock-console" \ --image-name "172.30.163.181:5000/twistlock/private:console_" \ --service-type "ClusterIP" \ --helm ``` 3. **Prisma Cloud Console + manually provisioned PersistentVolume + image pulled from the Prisma Cloud cloud registry.** If you omit the *--image-name* flag, the Prisma Cloud cloud registry is used by default, and you are prompted for your access token. ``` $ /twistcli console export openshift \ --persistent-volume-labels "app-volume=twistlock-console" \ --service-type "ClusterIP" \ --helm ``` 2. Unpack the chart into a temporary directory. ``` $ mkdir helm-console $ tar xvzf twistlock-console-helm.tar.gz -C helm-console/ ``` 3. Open *helm-console/twistlock-console/templates/securitycontextconstraints.yaml* for editing. 4. Change `apiVersion` from `v1` to `security.openshift.io/v1`. ```yaml {{- if .Values.openshift }} apiVersion: security.openshift.io/v1 kind: SecurityContextConstraints metadata: name: twistlock-console ... ``` 5. Repack the Helm chart ``` $ cd helm-console/ $ tar cvzf twistlock-console-helm.tar.gz twistlock-console/ ``` 6. Install the updated Helm chart. ``` $ helm install --namespace=twistlock -g twistlock-console-helm.tar.gz ``` ### Create an external route to Console Create an external route to Console so that you can access the web UI and API. 1. From the OpenShift web interface, go to the *twistlock* project. 2. Go to **Application > Routes**. 3. Select **Create Route**. 4. Enter a name for the route, such as **twistlock-console**. 5. Hostname = URL used to access the Console, e.g. *twistlock-console.apps.ose.example.com* 6. Path = **/** 7. Service = **twistlock-console** 8. Target Port = 8083 → 8083 9. Select the **Security > Secure Route** radio button. 10. TLS Termination = Passthrough (if using 8083) If you plan to issue a [custom certificate for Console TLS communication](/admin-guide/33/configure/certificates.md) that is trusted and will allow the TLS establishment with the Prisma Cloud Console, then Select Passthrough TLS for TCP port 8083. 11. Insecure Traffic = **Redirect** 12. Click **Create**. ### Create an external route to Console for external Defenders If you are planning to deploy Defenders to another cluster and report to this Console, you will need to create an additional external route to Console so that the Defenders can access the Console. You need to expose the Prisma Cloud-Console service’s TCP port 8084 as external OpenShift routes. Each route will be an unique, fully qualified domain name. 1. From the OpenShift web interface, go to the *twistlock* project. 2. Go to **Application > Routes**. 3. Select **Create Route**. 4. Enter a name for the route, such as **twistlock-console-8084**. 5. Hostname = URL used to access the Console, using a different hostname, e.g. *twistlock-console-8084.apps.ose.example.com* 6. Path = **/** 7. Service = **twistlock-console** 8. Target Port = 8084 → 8084 9. Select the **Security > Secure Route** radio button. 10. TLS Termination = Passthrough (if using 8084) The Defender to Console communication is a mutual TLS secure websocket session. This communication cannot be intercepted. 11. Insecure Traffic = **Redirect** 12. Click **Create**. ### Configure Console Create your first admin user, enter your license key, and configure Console’s certificate so that Defenders can establish a secure connection to it. 1. In a web browser, navigate to the external route you configured for Console, e.g. **. 2. Create your first admin account. 3. Enter your license key. 4. Add a SubjectAlternativeName to Console’s certificate to allow Defenders to establish a secure connection with Console. Use either Console’s service name, *twistlock-console* or *twistlock-console.twistlock.svc*, or Console’s cluster IP. Additionally, if a route for external Defenders was created, add that one to the SAN list too: *twistlock-console-8084.apps.ose.example.com* ``` $ oc get svc -n twistlock NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) twistlock-console LoadBalancer 172.30.41.62 172.29.61.32,172.29.61.32 8084:3184... ``` 1. Go to **Manage > Defenders > Names**. 2. Click **Add SAN** and enter Console’s service name. 3. Click **Add SAN** and enter Console’s cluster IP.
install openshift san
## Appendix: NFS PersistentVolume example Create an NFS mount for the Prisma Cloud Console’s PV on the host that serves the NFS mounts. 1. **mkdir /opt/twistlock\_console** 2. Check selinux: **sestatus** 3. **chcon -R -t svirt\_sandbox\_file\_t -l s0 /opt/twistlock\_console** 4. **sudo chown nfsnobody /opt/twistlock\_console** 5. **sudo chgrp nfsnobody /opt/twistlock\_console** 6. Check perms with: **ls -lZ /opt/twistlock\_console** (drwxr-xr-x. nfsnobody nfsnobody system\_u:object\_r:svirt\_sandbox\_file\_t:s0) 7. Create **/etc/exports.d/twistlock.exports** 8. In the **/etc/exports.d/twistlock.exports** add in line **/opt/twistlock\_console \*(rw,root\_squash)** 9. Restart nfs mount **sudo exportfs -ra** 10. Confirm with **showmount -e** 11. Get the IP address of the Master node that will be used in the PV (eth0, openshift uses 172. for node to node communication). Make sure TCP 2049 (NFS) is allowed between nodes. 12. Create a PersistentVolume for Prisma Cloud Console. The following example uses a label for the PersistentVolume and the [volume and claim pre-binding](https://docs.openshift.com/container-platform/3.10/dev_guide/persistent_volumes.html#persistent-volumes-volumes-and-claim-prebinding) features. The PersistentVolumeClaim uses the `app-volume: twistlock-console` label to bind to the PV. The volume and claim pre-binding `claimref` ensures that the PersistentVolume is not claimed by another PersistentVolumeClaim before Prisma Cloud Console is deployed. ```yaml apiVersion: v1 kind: PersistentVolume metadata: name: twistlock labels: app-volume: twistlock-console storageClassName: standard spec: capacity: storage: 100Gi accessModes: - ReadWriteOnce nfs: path: /opt/twistlock_console server: 172.31.4.59 persistentVolumeReclaimPolicy: Retain claimRef: name: twistlock-console namespace: twistlock ``` ## Appendix: Implementing SAML federation with a Prisma Cloud Console inside an OpenShift cluster When federating Prisma Cloud Console that is accessed through an OpenShift external route with a SAML v2.0 Identity Provider (IdP), the SAML authentication request’s *AssertionConsumerServiceURL* value must be modified. Prisma Cloud automatically generates the *AssertionConsumerServiceURL* value sent in a SAML authentication request based on Console’s configuration. When Console is accessed through an OpenShift external route, the URL for Console’s API endpoint is most likely not the same as the automatically generated *AssertionConsumerServiceURL.* Therefore, you must configure the *AssertionConsumerServiceURL* value that Prisma Cloud sends in the SAML authentication request. 1. Log into Prisma Cloud Console. 2. Go to **Manage > Authentication > SAML**. 3. In **Console URL**, define the *AssertionConsumerServiceURL*. In this example, enter ** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.prismacloud.io/admin-guide/33/install/deploy-console/console-on-openshift.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.