Deploy Prisma Cloud Defenders
Table of Contents
Deploy Prisma Cloud Defenders
To take advantage of the agent-based security features of Prisma Cloud, you must deploy the Defender agent.
You can deploy single Defenders for containers, hosts, and serverless functions or deploy Defenders on entire clusters using an orchestrator.
There are several Defender types based on the assets they protect and how you wish to deploy them.
Defender capabilities
The following table summarizes the key functional differences between Defender types.
Capabilities | Defender type | ||||
|---|---|---|---|---|---|
Container 1 | Host | Serverless | App-Embedded | ||
Deployment methods | Console UI | Y | Y | Y | Y |
API | Y | Y | Y | Y | |
twistcli | Y | Y | |||
Vulnerability management | Y | Y | Y 2 | Y 3 | |
Compliance | Y | Y | Y 2 | Y 4 | |
Runtime defense | Behavioral modeling | Y | |||
Process | Y | Y | Y | Y | |
Networking | Y | Y | Y | Y | |
File system | Y | Y | Y | Y | |
Forensics | Y | Y | Y | ||
Access control | Kubernetes auditing | Y 5 | Y 5 | ||
Admission control | Y | ||||
Firewalls | WAAS | Y | Y | Y | Y |
CNNS | Y | Y | |||
Radar (visualization) | Radar | Y | Y | Y | |
1
Container Defender supports all Host Defender capabilities.
You can deploy single container and host Defenders or deploy container and host Defenders using an orchestrator.2
Normally Defender scans workloads for vulnerabilities and compliance issues.
For serverless functions, Console does the scanning.
In the Console, create a configuration that points to your repository of functions in your cloud provider.3
Vulnerability management for deployed images only.
Registry scanning by app-embedded Defenders is not supported.4
Image compliance and custom compliance checks only.
The trusted images feature isn’t supported.5
Kubernetes auditing is done by the Console, and not by the Defenders.
In the Console, enable Kubernetes auditing and create a configuration that points to your cluster.Connectivity
Defender must be able to communicate with Prisma Cloud over the network because it pulls policies down and sends data (alerts, events, etc) back to the Prisma Cloud console.
If you are using a certificate authority through a proxy, add the --proxy-cacert flag to the curl command as described in the curl documentation.
In simple environments, where your hosts run on the same subnet, you can connect to Console using the host’s IP address or hostname.
In more complex environments, where your setup runs in the cloud, it can be more difficult to determine how Defender connects to Console.
When setting up Defender, use whichever address routes over your configuration and lets Defender connect to Console.
For example, Console might run in one Virtual Private Cloud (VPC) in AWS, and your containers might run in another VPC.
Each VPC might have a different RFC1918 address space, and communication between VPCs might be limited to specific ports in a security group.
Use whichever address lets Defender connect to Console.
It might be a publicly exposed IP address, a hostname registered with a DNS, or a private address NAT’ed to the actual IP address assigned to Console.
For more information about setting up name resolution in complex networks, see
Best practices for for DNS and certificate management.
Deployment Scenarios
Install the Defender type that best secures the resource you want to protect.
Install Defender on each host that you want Prisma Cloud to protect.
Container Defenders protect both the containers and the underlying host.
Host Defenders are designed for legacy hosts that have no capability for running containers.
Host Defenders protect the host only.
For serverless technologies, embed Defender directly in the resource.
The scenarios here show examples of how the various Defender types can be deployed.
Scenario #1
Stand-alone Container Defenders are installed on hosts that are not part of a cluster.
Stand-alone Container Defenders might be required in any number of situations.
For example, a very simple evaluation setup might consist of two virtual machines.
- 1— One VM runs Onebox (Console + Container Defender).
- 2— To protect the container workload on a second VM, install another stand-alone Container Defender.
Scenario #2
For clusters, such as Kubernetes and OpenShift, Prisma Cloud utilizes orchestrator-native constructs, such as DaemonSets, to guarantee that Defender runs on every node in the cluster.
For example, the following setup has three different types of Defender deployments.
- 1— In the cluster, Container Defenders are deployed as a DaemonSet. (Assume this is a Kubernetes cluster; it would be a similar construct, but with a different name, for AWS ECS etc).
- 2— On the host dedicated to scanning registry images, which runs outside the cluster, a stand-alone Container Defender is deployed.
- 3— On the legacy database server, which doesn’t run containers at all, a Host Defender is deployed. Host Defenders are a type of stand-alone Defender that run on hosts that don’t have Docker installed.
Scenario #3
Managed services that run functions and containers on-demand isolate the runtime from the underlying infrastructure.
In these types of environments, Defender cannot access the host’s operating system with elevated privileges to observe activity and enforce policies in the runtime.
Instead, Defender must be built into the runtime, and control application execution and detect and prevent real-time attacks from within.
App Embedded Defender can be deployed to protect any container, regardless of the platform or runtime, whether it’s Docker, runC, or Diego on Tanzu Application Service.
- 1— Serverless Defender is embedded into each AWS Lambda function.
