App-Embedded Defender for Fargate

App-Embedded Defenders for Fargate monitor and protect your Fargate tasks to ensure they execute as designed.
To learn when to use App-Embedded Defenders, see Defender types.
To learn more about App-Embedded Defender’s capabilities, see:
For front-end Farate tasks, deploy the WAAS application firewall for additional runtime protection.

Architecture

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>:<UIID>
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:
  1. 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.
  2. Embed the Fargate Defender into your task definition.
  3. 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 showed 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 cmd instructions. We override these values to first run the App-Embedded Defender, and then run the original entrypoint/cmd 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 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 cmd 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
If your task definition specifies the command parameter, but no entrypoint, AND you’ve enabled Prisma Cloud’s automatic entrypoint extraction, then Prisma Cloud will bypass automatic entrypoint extraction, and instead generate a protected task definition using the command parameter.

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.
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.
  • You have already created an ECS cluster.
  • Cluster VPC and subnets.
  • Task role.
  • Your image has a shell.
You can optionally run the Fargate Defender sidecar as a non-essential container. This configuration isn’t recommended because Defender’s goal is to ensure that tasks are always protected.
If you’ve configured Defender as a non-essential container and you’re having issues with your setup, first validate that Defender is running as expected before contacting Palo Alto Networks customer support. By setting Defender as non-essential, there is no guarantee that Defender is running, and validating that it’s running is the first step in debugging such issues.

Supported task definition formats

Prisma Cloud supports the following task definition formats:
  • Standard JSON format, as described here.
  • CloudFormation templates for AWS::ECS::TaskDefinition in JSON and YAML formats, as described here. You can use either just the task definition part of the CloudFormation template, or a full CloudFormation template.
Example of a standard JSON format task definition:
{ "containerDefinitions": [ { "name": "web", "image": "nginx", "entryPoint": [ "/http_server" ] } ], "cpu": "256", "executionRoleArn": "arn:aws:iam::112233445566:role/ecsTaskExecutionRole", "family": "webserver", "memory": "512", "networkMode": "awsvpc", "requiresCompatibilities": [ "FARGATE" ] }
Example of the equivalent task definition as a JSON CloudFormation template:
{ "Type" : "AWS::ECS::TaskDefinition", "Properties": { "ContainerDefinitions": [ { "Name": "web", "Image": "nginx", "EntryPoint": [ "/http_server" ] } ], "Cpu" : 256, "ExecutionRoleArn": "arn:aws:iam::112233445566:role/ecsTaskExecutionRole", "Family": "webserver", "Memory" : 512, "NetworkMode" : "awsvpc", "RequiresCompatibilities" : [ "FARGATE" ] } }
Example of a full JSON CloudFormation template that includes a Fargate task definition:
{ "AWSTemplateFormatVersion": "2010-09-09", "Resources": { "fargateTaskDefinition": { "Type": "AWS::ECS::TaskDefinition", "Properties": { "ExecutionRoleArn": "arn:aws:iam::1234567891234:role/ecsTaskExecutionRole", "ContainerDefinitions": [ { "Name": "test-server", "Image": "1234567891234.dkr.ecr.us-east-1.amazonaws.com/user:ubuntu-test-server", "MemoryReservation": "", "Essential": true, "PortMappings": [], "Cpu": 256, "Memory": 512, "EntryPoint": [ "/http_server" ], "EnvironmentFiles": [], "LogConfiguration": { "LogDriver": "awslogs", "Options": { "awslogs-group": "/ecs/user-tracer-test", "awslogs-region": "us-east-1", "awslogs-stream-prefix": "ecs" } } } ], "Memory": "512", "TaskRoleArn": "arn:aws:iam::1234567891234:role/ecsTaskExecutionRole", "Family": "TASK-NAME", "RequiresCompatibilities": [ "FARGATE" ], "NetworkMode": "awsvpc", "Cpu": "256", "InferenceAccelerators": [], "Volumes": [], "Tags": [] } }, "HelloLambdaRole": { "Type": "AWS::IAM::Role", "Properties": { "RoleName": "HelloLambdaRole1", "AssumeRolePolicyDocument": { "Statement": [ { "Effect": "Allow", "Principal": { "Service": "lambda.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } } } } }
Example of a full YAML CloudFormation template that includes a Fargate task definition:
AWSTemplateFormatVersion: "2010-09-09" Resources: fargateTaskDefinition: Type: 'AWS::ECS::TaskDefinition' Properties: ExecutionRoleArn: 'arn:aws:iam::1234567891234:role/ecsTaskExecutionRole'