Defender types
Defenders enforce the policies you set in Console.
They come in a number of different flavors.
Each flavor is designed for protecting specific types of cloud-native resources and for optimal deployment into the environment, with full support for automated workflows.
Use the following flow chart to choose the best Defender for the job.
In general, deploy Container Defender whenever you can.
It offers the most features, it can simultaneously protect both containers and host, and nothing needs to be embedded inside your containers for Defender to be able to protect them.
Container Defender (Linux and Windows)
Install Container Defender on any host that runs a container workload.
Container Defender protects both your containers and the underlying host.
Docker must be installed on the host because this Defender type runs as a container.
Container Defender offers the richest set of capabilities.
The deployment is also the simplest.
After deploying Container Defender to a host, it can immediately protect and monitor your containers and host.
No additional steps are required to rebuild your containers with an agent inside.
Container Defender should always be your first choice whenever possible.
There are some minimum requirements to run Container Defender.
You should have full control over the host where Container Defender runs.
It must be able to run alongside the other containers on the host with select kernel capabilities.
And it must be able to run in the host’s network and process namespace.
Deploy one Container Defender per host.
Container Defender can be deployed in several ways:
- With cluster constructs. Container orchestrators often provide native capabilities for deploying agents, such as Defender, to every node in the cluster. Prisma Cloud leverages these capabilities to install Defender. Kubernetes and OpenShift, for example, offer DaemonSets, and Docker Swarm offers global services. As such, Container Defender is deployed as a DaemonSet on Kubernetes and a global service on Swarm.
- As a stand-alone entity. Stand-alone Container Defenders are installed on hosts that are not part of a cluster.
Host Defender (Linux and Windows)
Host Defender utilizes Prisma Cloud’s model-based approach for protecting hosts that do not run containers.
This Defender type lets you extend Prisma Cloud to protect all the hosts in your environment, regardless of their purpose.
Defender runs as a systemd service on Linux and a Windows service on Windows.
If Docker Engine is detected on the host, installation of this Defender type is blocked; install Container Defender instead.
Deploy one Host Defender per host.
Do not deploy Host Defender if you’ve already deployed Container Defender to a host.
Container Defender offers the same host protection capabilities as Host Defender.
Serverless Defender
Serverless Defenders offer runtime protection for AWS Lambda functions.
Serverless Defender must be embedded inside your functions.
Deploy one Serverless Defender per function.
App Embedded Defender
App Embedded Defenders offer runtime protection for containers.
Deploy App Embedded Defender anywhere you can run a container, but you can’t run Container Defender.
Container-on-demand services are a typical use case for App Embedded Defender.
They abstract away the underlying cluster, host, operating system, and software modules (such as Docker Engine) and present them as a single black box.
Hooks into the operating system that Container Defender needs to monitor and protect resources aren’t available in these environments.
Instead, embed App Embedded Defender directly inside the container to establish a point of control.
Prisma Cloud supports an automated workflows for embedding App Embedded Defenders.
Deploy one App Embedded Defender per container.
For Fargate, deploy one Defender per task.
App Embedded Defender offers three deployment mechanisms: Fargate, Dockerfile, and manual.
Fargate
If you have an AWS Fargate task, deploy App Embedded Fargate Defender.
A key attribute of the App Embedded Fargate Defender is that you don’t need to change how the container images in the task are built.
The process of embedding the App Embedded Defender simply manipulates the task definition to inject a Prisma Cloud sidecar container, and start existing task containers with a new entrypoint, where the entrpoint binary is hosted by the Prisma Cloud sidecar container.
The transformation of an unprotected task to a protected task takes place at the task definition level only.
The container images in the task don’t need to be manually modified.
This streamlined approach means that you don’t need to maintain two versions of an image (protected and unprotected).
You simply maintain the unprotected version, and when you protect a task, Prisma Cloud dynamically injects App Embedded Defender into it.
The Prisma Cloud sidecar container has a couple of jobs:
- Hosts the Defender binary that gets injected into containers in the task.
- Proxies all communication to Console. Even if you have multiple containers in a task, it appears as a single entity in Console’s dashboard.
- Synchronizes policy with Console and sends alerts to Console.
Dockerfile
The Docker image format, separate from the runtime, is becoming a universal runnable artifact.
If you’re not using Fargate, but something else that runs a Docker image, such as Azure Container Instances or Pivotal PAS, embed App Embedded Defender using the Dockerfile method.
Provide a Dockerfile, and Prisma Cloud returns a new version of the Dockerfile in a bundle.
Rebuild the new Dockerfile to embed Prisma Cloud into the container image.
When the container starts, Prisma Cloud App Embedded Defender starts as the parent process in the container, and it immediately invokes your program as its child.
There are two big differences between this approach and the Fargate approach:
- With the Fargate approach, you don’t change the actual image. With the Dockerfile approach, you have the original image and a new protected image. You must modify the way your containers are built to embed App Embedded Defender into them. You need to make sure you tag and deploy the right image.
- Each Defender binary makes it’s own connection to Console. In the Console dashboard, they are each counted as unique applications.
Nothing prevents you from protecting a Fargate task using the Dockerfile approach, but it’s inefficient.
Manual
Use the manual approach to protect almost any type of runtime.
If you’re not running a Docker image, but you still want Prisma Cloud to protect it, deploy App Embedded Defender with the manual method.
Download the App Embedded Defender, set up the required environment variables, then start your program as an argument to the App Embedded Defender.
If you choose the manual approach, you have to figure out how deploy, maintain, and upgrade your app on your own.
While the configuration is more complicated, it’s also the most universal option because you can protect almost any executable.
PCF Defender
PCF Defenders run on your PCF infrastructure and scan the droplets in your blobstores for vulnerabilities.
The PCF Defender is delivered as a tile that can be installed from your PCF Ops Manager Installation Dashboard.
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 | ||
Runtime defense | Behavioral modeling | Y | Y | ||
Process | Y | Y | Y | Y | |
Networking | Y | Y | Y | Y | |
File system | Y | Y | Y | ||
Forensics | Y | Y | |||
Firewalls | CNAF | Y | Y | Y | Y |
CNNF | Y | Y | |||
Radar (visualization) | Y | Y | |||
1
Container Defender also supports all of the Host Defender capabilities.2
Serverless functions are scanned for vulnerabilities and compliance by Container Defender.
In Console, create a configuration that points to your repository of functions in your cloud provider.3
Set up your Jenkins build to scan your container images before they’re pushed to the repository.Connectivity
Defender must be able to communicate with Console over the network because it pulls policies down and sends data (alerts, events, etc) back to Console.
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, OpenShift, and Swarm, 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 Swarm, DC/OS, 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 PCF.
- 1— Serverless Defender is embedded into each AWS Lambda function.
