When you embed the App-Embedded Defender into your Fargate task, Prisma Cloud modifies the task definition. The updated task definition includes a Prisma Cloud sidecar container. The sidecar container handles all communication with Console, including retrieving policies and sending audits. It also hosts the App-Embedded Defender binaries, which are shared with the task’s other containers through a shared volume. The embed process modifies each containerDefinition to:

Mount the Prisma Cloud sidecar container’s shared volume to gain access to the App-Embedded Defender binaries.

Start the original entrypoint command under the control of App-Embedded Defender.

App-Embedded Defenders do not communicate directly with Console. All communication is proxied through the Prisma Cloud sidecar container.

App ID

Each App-Embedded Defender deployed in an ECS Fargate task has an App ID that’s automatically generated during the embed flow. For ECS Fargate tasks, the App ID is constructed from the task name and an internally generated UUID. The format is:

<task-name>:<UUID>

This App ID is used throughout the Console UI. In particular, it’s listed in the Apps
column of the vulnerability and compliance scan reports under Monitor > Vulnerabilities > Images > Deployed
and Monitor > Compliance > Images > Deployed
.

WAAS for Fargate

All the capabilities of standard WAAS are available for Fargate tasks. The only difference is that Fargate Defenders run as a reverse proxies to all other containers in the task. As such, when you set up WAAS for Fargate, you must specify the exposed external port where Fargate Defender can listen, and the port (not exposed to the Internet) where your web application listens. WAAS for Fargate forwards the filtered traffic to your application port - unless an attack is detected and you chose Prevent
in your WAAS for Fargate rule.

For more information on the type of attacks that Prisma Cloud detects and prevents, see Prisma Cloud WAAS.

Securing Fargate tasks

To secure a Fargate task, embed the Prisma Cloud Fargate Defender into it. The steps are:

Define your policy in Prisma Cloud Console.

App-Embedded Defenders dynamically retrieve rules from Console as they are updated. You can embed the App-Embedded Defender into a task with a simple initial policy, and then refine it later, as needed.

Embed the Fargate Defender into your task definition.

Start the service.

When securing Fargate tasks with runtime rules and WAAS, target rules to tasks using the Scope
fields. For runtime, create new collections or use already defined collections scoped by image and container name, as shown in the image below. Policy is applied per-container in the task.

For WAAS, scope rules by App ID. Policy is applied per-task. The WAAS firewall listens on a specific port, and since all containers run in the same network namespace, it applies to the entire task.

Task entrypoint

When Prisma Cloud generates a protected task definition, it needs to know the container image’s entryPoint and/or command instructions. We override these values to first run the App-Embedded Defender, and then run the original entryPoint/command under Defender’s watch.

Setting the entrypoint in a task definition is optional. It’s only required when you want to override the image’s entrypoint as specified in its Dockerfile. As such, many task definitions don’t explicitly specify it. However, Prisma Cloud needs to know what it is, so it can run the original app under Defender’s control. To aid in embedding Defender into Fargate tasks without any manual intervention (i.e. updating task definitions to explicitly specify entrypoints), Prisma Cloud can automatically find the image’s entrypoint and set it up in the protected task definition.

Prisma Cloud can find the image’s entrypoint from:

Registry scans. When Prisma Cloud scans an image from a registry, it saves the entryPoint and command parameters to the database. When embedding Defender into a task, Prisma Cloud searches the database to see if it’s seen the task’s image before. If so, it extracts the original entrypoint, and sets it up in the new protected task definition.

Querying the registry directly. If the image hasn’t been scanned by the registry scanner, then you can point Prisma Cloud to the registry where the image lives, and Prisma Cloud can find and extract the entrypoint. Prisma Cloud supports the following registries:

AWS Elastic Container Registry (ECR).

Docker Registry v2.

JFrog Artifactory.

Automatically extracting the entrypoint using one of the methods described above is optional. It can be enabled or disabled when embedding Defender in a task definition.

The twistcli tool also supports entrypoint extraction when generating protected task definitions. For more information, see the help menu:

twistcli app-embedded generate-fargate-task --help

Embedding App-Embedded Defender into Fargate tasks

Prisma Cloud cleanly separates the code developers produce from the Fargate containers we protect. Developers don’t need to change their code to accommodate Prisma Cloud. They don’t need to load any special libraries, add any files, or change any manifests. When a container is ready to be deployed to test or production, run your task definition through our transform tool to automatically embed the Fargate Defender, then load the new task definition into AWS.

The method for embedding the Fargate Defender was designed to seamlessly integrate into the CI/CD pipeline. You can call the Prisma Cloud API to embed the Fargate Defender into your task definition.

Prisma Cloud doesn’t support Intrinsic functions in AWS CloudFormation template.

Prerequisites:

The task where you’re embedding the App-Embedded Defender can reach Console over the network. Defender uses port 443 to connect to the Prisma Cloud Console.

You have a task definition.

Document:Prisma Cloud Administrator’s Guide (Compute)

Deploy App-Embedded Defender for Fargate

Table of Contents