1. Overview

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 a YAML configuration file for 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 Defender.

Prisma Cloud Defenders are deployed as a DeamonSet, which guarantees that an instance of Defender runs on each worker node in the cluster.

1.1. 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 pivot

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 corresponding kubeconfig file saved in the credentials store. 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.

Radar lets you explore your environment cluster-by-cluster. 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 can all be scoped by cluster name.

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 in Manage > 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.

2. Preflight checklist

To ensure that your installation goes smoothly, work through the following checklist and validate that all requirements are met.

2.1. General

  • You have a valid Prisma Cloud license key and access token.

2.2. 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).

2.3. Runtimes

  • Prisma Cloud supports Docker Engine, CRI-O, and cri-containerd. For more information, see the system sequirements

2.4. Permissions

  • You can create and delete namespaces in your cluster.

  • You can run kubectl create commands.

2.5. Firewalls and ports

Validate that the following ports are open.

Prisma Cloud Defenders:

  • Incoming: None

  • Outgoing: 443

3. Install Prisma Cloud

Use twistcli to install the Prisma Cloud Defenders in your Kubernetes cluster. The twistcli utility is included with every release.

The main criteria for installing Defender is that it can connect to the Prisma Cloud Compute Console SaaS service. Defender connects to Console via websocket over port 443 to retrieve policies and send data

3.1. Install Defender

Defender is installed as a DaemonSet, which ensures that an instance of Defender runs on every node in the cluster. Use twistcli to generate a YAML configuration file for the Defender DaemonSet, then deploy it using kubectl. You can use the same method to deploy Defender DaemonSets from both macOS and Linux kubectl-enabled cluster controllers.

The benefit of declarative object management, where you work directly with YAML configuration files, is that you get the full "source code" for the objects you create in your cluster. You can use a version control tool to manage and track modifications to config files so that you can delete and reliably recreate DaemonSets in your environment.

If you don’t have kubectl access to your cluster, you can deploy Defender DaemonSets directly from the Console UI.

The following procedure shows you how to deploy Defender DaemonSets with twistcli using declarative object management. Alternatively, you can generate Defender DaemonSet install commands in the Console UI under Manage > Defenders > Deploy > DaemonSet. Install scripts work on Linux hosts only. For macOS and Windows hosts, use twistcli to generate Defender DaemonSet YAML configuration files, and then deploy it with kubectl, as described in the following procedure.
If you’re using CRI-O or containerd, pass the --cri flag to twistcli (or enable the CRI option in the Console UI) when generating the Defender YAML or Helm chart.
For provider managed clusters, Prisma Cloud automatically gets the cluster name from the cloud provider. To override the the cloud provider’s cluster name, use the --cluster option. For self-managed clusters, such as those built with kops, you must manually specify a cluster name with the --cluster option.
  1. Retrive Console’s API address (PRISMA_CLOUD_COMPUTE_CONSOLE_API_ADDR).

    1. Sign into Prisma Cloud.

    2. Go to Compute > Manage > System > Downloads.

    3. Copy the URL under Path to Console.

  2. Retrieve Console’s service address (PRISMA_CLOUD_COMPUTE_SVC_ADDR).

    The service address can be derived from the API address by removing the protocol scheme and path. It is simply the host part of the URL.

    1. Go to Compute > Manage > Defenders > Deploy > DaemonSet

    2. Copy the address from 1 (The name that clients and Defenders use to access this Console).

  3. Generate a defender.yaml file, where:

    The following command connects to Console’s API (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, or Console’s service address.

    $ <PLATFORM>/twistcli defender export kubernetes \
      --address <PRISMA_CLOUD_COMPUTE_CONSOLE_API_ADDR>
      --user <ADMIN_USER> \
      --cluster-address <PRISMA_CLOUD_COMPUTE_SVC_ADDR>
    • <PLATFORM> can be linux, osx, or windows.

    • <ADMIN_USER> is the name of a Prisma Cloud user with the System Admin role.

  4. Deploy the Defender DaemonSet.

    $ kubectl create -f defender.yaml
  5. In Prisma Cloud, go to Compute > Manage > Defenders > Manage > DaemonSets to see a list of deployed Defenders.

4. Install Prisma Cloud on a CRI (non-Docker) cluster

Kubernetes lets you set up a cluster with the container runtime of your choice. Prisma Cloud supports Docker Engine, CRI-O, and cri-containerd.

4.1. Deploying Defender DaemonSets

When generating the YAML file to deploy the Defender DaemonSet, a toggle lets you select your runtime environment. Since Defenders need to have a view of other containers, this option is necessary to guide the communication. By default the toggle is off Prisma Cloud uses Docker Engine. When the toggle is on, Prisma Cloud generates the propper yaml for the CRI Kubernetes environment.

If you use containerd on GKE, and you install Defender without the CRI switch, everything will appear to work properly, but you’ll have no images or container scan reports in Monitor > Vulnerability and Monitor > Compliance pages and you’ll have no runtime models in Monitor > Runtime. This happens because the Google Container Optimized Operating system (GCOOS) nodes have Docker Engine installed, but Kubernetes doesn’t use it. Defender thinks everything is OK because all of the integrations succeed, but the underlying runtime is actually different.
cri toggle

If you’re deploying Defender DaemonSets with twistcli, use the --cri option to use to specify the runtime interface. By default (no flag), twistcli generates a configuration that uses Docker Engine. With the --cri flag, twistcli generates a configuration that uses CRI.

$ <PLATFORM>/twistcli defender export kubernetes \
  --cri
  --address https://yourconsole.example.com:8083 \
  --user <ADMIN_USER> \
  --cluster-address yourconsole.example.com

When generating YAML from Console or twistcli, there is a simple change to the yaml file as seen below.

In this abbreviated version DEFENDER_TYPE:daemonset will use the Docker interface.

...
spec:
  template:
    metadata:
      labels:
        app: twistlock-defender
    spec:
      serviceAccountName: twistlock-service
      restartPolicy: Always
      containers:
      - name: twistlock-defender-19-03-321
        image: registry-auth.twistlock.com/tw_<token>/twistlock/defender:defender_19_03_321
        volumeMounts:
        - name: host-root
          mountPath: "/host"
        - name: data-folder
          mountPath: "/var/lib/twistlock"
          ...
        env:
        - name: WS_ADDRESS
          value: wss://yourconsole.example.com:8084
        - name: DEFENDER_TYPE
          value: daemonset
        - name: DEFENDER_LISTENER_TYPE
          value: "none"
          ...

In this abbreviated version DEFENDER_TYPE:cri will use the CRI.

...
spec:
  template:
    metadata:
      labels:
        app: twistlock-defender
    spec:
      serviceAccountName: twistlock-service
      restartPolicy: Always
      containers:
      - name: twistlock-defender-19-03-321
        image: registry-auth.twistlock.com/tw_<token>/twistlock/defender:defender_19_03_321
        volumeMounts:
        - name: host-root
          mountPath: "/host"
        - name: data-folder
          mountPath: "/var/lib/twistlock"
          ...
        env:
        - name: WS_ADDRESS
          value: wss://yourconsole.example.com:8084
        - name: DEFENDER_TYPE
          value: cri
        - name: DEFENDER_LISTENER_TYPE
          value: "none"
          ...

5. Install Prisma Cloud with Helm charts

You can use twistcli to create Helm charts for Prisma Cloud Defender. Helm is a package manager for Kubernetes, and chart is the moniker for a Helm package.

Follow the main install flow, except:

  • Pass the --helm option to twistcli to generate a Helm chart. Other options passed to twistcli configure the chart.

  • Deploy Defender with helm install rather than kubectl create.

  1. Create a Defender DaemonSet Helm chart.

    $ <PLATFORM>/twistcli defender export kubernetes \
      --address https://yourconsole.example.com:8083 \
      --helm \
      --user <ADMIN_USER> \
      --cluster-address twistlock-console
  2. Install Defender.

    $ helm install \
      --namespace twistlock \
      --name twistlock-defender-ds \
      ./twistlock-defender-helm.tar.gz

6. DC/OS Kubernetes

Kubernetes on DC/OS uses nested vitualization, where K8S nodes are actually privileged containers. This abstraction creates a mismatch between the host PID namespace Defender needs to see, and the PID namespace it actually sees.

For installing Defender, pass the --containerized-host flag to twistcli when generating the DaemonSet deployment file. If you’re generating the DaemonSet deployment file from the Console UI, set the Nodes runs inside containerized environment option to On.

$ <PLATFORM>/twistcli defender export kubernetes \
  --address https://yourconsole.example.com:8083 \
  --user <ADMIN_USER> \
  --cluster-address twistlock-console \
  --containerized-host

7. Google Kubernetes Engine (GKE)

To install Prisma Cloud on Google Kubernetes Engine (GKE), use the standard Kubernetes install flow. Before getting started, create a ClusterRoleBinding, which grants the permissions required to create the Defender DaemonSet.

The Google Cloud Platform (GCP) service account that you use to create the Prisma Cloud Console resources, including Deployment controller and PersistentVolumeClaim, must have at least the Kubernetes Engine Developer role to be successful.

The GCP service account that you use to create the Defender resources, including DaemonSet, must have the Kubernetes cluster-admin role. If you try to create the Defender resources from a service account without this cluster-specific role, it will fail because the GCP Kubernetes Engine Developer role doesn’t grant the developer sufficient permissions to create a ClusterRole (one of the Defender resources). You’ll need to use an account with the GCP Kubernetes Engine Admin role to bind the Kubernetes cluster-admin role to your Kubernetes developer’s service account.

It’s probably best to create the ClusterRoleBinding before turning the cluster over any user (typically DevOps) tasked with managing and maintaing Prisma Cloud.

Run the command in the following procedure on ANY service account that attempts to apply the Defender Daemonset YAML or Helm chart, even if that service account already has elevated permissions with the GCP Kubernetes Engine Admin role. Otherwise, you’ll get an error.

The following procedure uses a service account named your-dev-user@your-org.iam.gserviceaccount.com that has the GCP Kubernetes Engine Developer role. You’ll also need access to a more privileged GCP account that has the Kubernetes Engine Admin role to create the ClusterRoleBinding in your cluster.

Prerequisites:

  • You have deployed a GKE cluster.

  • You have a Google Cloud Platform (GCP) service account with the Kubernetes Engine Developer role.

  • You have access to a GCP account with at least the Kubernetes Engine Admin role.

  1. With the service account that has the GCP Kubernetes Engine Admin role set as the active account, run:

    $ kubectl create clusterrolebinding your-dev-user-cluster-admin-binding \
      --clusterrole=cluster-admin \
      --user=your-dev-user@your-org.iam.gserviceaccount.com
  2. With the Kubernetes Engine Developer service account, continue with the standard Kubernetes install procedure for Prisma Cloud Console and Defenders, starting here.

8. Redeploying Defenders

To redeploy Defenders, generate a new DaemonSet YAML configuration file with twistcli:

$ <PLATFORM>/twistcli defender export kubernetes \
  --address https://yourconsole.example.com:8083 \
  --user <ADMIN_USER> \
  --cluster-address twistlock-console

Then apply the changes to your Defender pods. The kubectl apply command lets you make in-place updates to resources.

$ kubectl apply -f defender.yaml

9. Troubleshooting

9.1. Pod Security Policy

If 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 allowed

If 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:

PodSecurityPolicy
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: RunAsAny
ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 name: prismacloudcompute-defender-role
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs: ['use']
  resourceNames:
  - prismacloudcompute-service
ClusterRoleBinding
apiVersion: 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

9.2. Defender install issues in GKE

If you see the following error when trying to create the Defender DaemonSet, you’ve probably tried to create the Defender resources from a service account that has the GCP Kubernetes Engine Developer role. To fix the issue, grant the proper cluster role to the service account.

Error from server (Forbidden): error when creating "daemonset.yaml": clusterroles.rbac.authorization.k8s.io is forbidden: User "your-dev-user@your-org.iam.gserviceaccount.com" cannot create clusterroles.rbac.authorization.k8s.io at the cluster scope: Required "container.clusterRoles.create" permission.

Error from server (Forbidden): error when creating "daemonset.yaml": clusterrolebindings.rbac.authorization.k8s.io is forbidden: User "your-dev-user@your-org.iam.gserviceaccount.com" cannot create clusterrolebindings.rbac.authorization.k8s.io at the cluster scope: Required "container.clusterRoleBindings.create" permission.

If you see the following error when trying to create the Defender DaemonSet, you’ve probably tried to create the Defender resources from a service account with the Kubernetes Engine Admin role. To fix the issue, grant the proper cluster role to the service account.

Error from server (Forbidden): error when creating "daemonset.yaml": clusterroles.rbac.authorization.k8s.io "twistlock-view" is forbidden: attempt to grant extra privileges: [{[list] [rbac.authorization.k8s.io] [roles] [] []} {[list] [rbac.authorization.k8s.io] [rolebindings] [] []} {[list] [rbac.authorization.k8s.io] [clusterroles] [] []} {[list] [rbac.authorization.k8s.io] [clusterrolebindings] [] []}] user=&{your-admin-user@your-org.iam.gserviceaccount.com  [system:authenticated] map[user-assertion.cloud.google.com:[iVWgsppUtVXaN1xToHtXpQdi5jJy6jv7BlSUZSUNTMjI2N77AaL5zQwZse0rqdu0Bz/35+6CG//82jdATfqfEWxDIRdAYHGvzRweXDZxOvI4EZzhyUVVKHJKL6i6v47VlFsHtSMx63QiVWgsppUtVXaN1xToHtXpQmU3nNtlspQaH3RtqSLwK/MoqW3Cc+VkWmuxyGUCYcW94Ttd6euy8iVWgsppUtVXaN1xToHtXpQWhRRTxlidgQdMzAbcAAbbv2C/uMlWs4VkzII7i9l6EEg==]]} ownerrules=[{[create] [authorization.k8s.io] [selfsubjectaccessreviews selfsubjectrulesreviews] [] []} {[get] [] [] [] [/api /api/* /apis /apis/* /healthz /openapi /openapi/* /swagger-2.0.0.pb-v1 /swagger.json /swaggerapi /swaggerapi/* /version /version/]}] ruleResolutionErrors=[]

10. Uninstall

To uninstall Prisma Cloud, delete the twistlock namespace. Deleting a namespace deletes everything under it.

  1. Delete the twistlock namespace.

    $ kubectl delete namespaces twistlock