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 As such, Container Defender is deployed as a DaemonSet on Kubernetes
- 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 Defenders offer runtime protection for AWS Lambda functions. Serverless Defender must be embedded inside your functions. Deploy one Serverless Defender per function.
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.
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