App-Embedded Defender for Fargate

App-Embedded Defenders for Fargate monitor your tasks to ensure they execute as designed, protecting tasks from suspicious processes and outbound network connections.
App-Embedded Defender policies let you define:
  • Process allow or deny lists. Enables verification of launched processes against policy.
  • Outgoing connections allow or deny lists. Enables verification of domain name resolution against policy for outgoing network connections.
Besides runtime policy, you can also configure the WAAS application firewall to protect front-end Fargate tasks.


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. The following diagram illustrates the setup:

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
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. By default, there are no rules in the App-Embedded runtime policy. App-Embedded Defenders dynamically retrieve policies from Console as they are updated. You can embed the App-Embedded Defender into a task with very simple initial policies, then refine them 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
fields. For runtime, scope rules by image and container name. 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.

Embed 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 accomodate 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 a 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.
  • The task where you’re embedding the App-Embedded Defender can reach Console’s port 8084 over the network.
  • You have a task definition.
  • You have already created an ECS cluster.
  • Cluster VPC and subnets.
  • Task role.
Your task definition must include matching entrypoint and cmd parameters from the Dockerfile(s) of the image(s) in your task. Because Prisma Cloud does not see the actual images as part of the embedding flow, it depends on having these parameter present to reliably insert the App-Embedded Defender into the task startup flow. If your Dockerfile does not include an entrypoint parameter, a default one, such as /bin/sh, must be used in the task definition. However, because the cmd parameter is optional, if your Dockerfile does not include a cmd parameter, one is not required in the task definition.
  1. Log into Prisma Cloud Console.
  2. Go to
    Manage > Defenders > Deploy > Defenders
  3. Select
    Single defender
  4. In the first drop-down list, choose the name or IP address App-Embedded Defender should use to connect to Console.
    A list of IP addresses and hostnames are pre-populated in the drop-down list. If none of the items are valid, select the
    tab and add a new subject alternative name (SAN) using
    Add SAN
    button. After adding a SAN, your IP address or hostname will be available in the drop-down list in the
    Selecting an IP address in a evaluation setup is acceptable, but using a DNS name is more resilient. If you select Console’s IP address, and Console’s IP address changes, your Defenders will no longer be able to communicate with Console.
  5. In the
    Defender Type
    drop-down list, choose
  6. Set the
    Deploy App-Embedded Defender
    Fargate Task
  7. Embed the Fargate Defender into your task definition.
    1. Copy and paste your task definition into the left-hand box.
    2. Click
      Generate Protected Task
    3. Copy the updated task definition from the right-hand box.

Creating a task definition in AWS

Create a new task definition in AWS with the output from the previous section. If you already have an existing task definition, create a new revision.
This section is geared to creating a new task definition based on the sample task.
  1. Log into the AWS Management Console.
  2. Go to
    Services > ECS
  3. Click
    Task Definitions
    , then click
    Create new Task Definition
    1. Select
      , then click
      Next step
    2. Scroll to the bottom of the page, and click
      Configure via JSON
    3. Delete the prepopulated JSON, then paste the JSON generated for task from the previous section.
    4. Click
  4. Validate task content.
    1. Task name should be as described in the JSON.
    2. Select the
      Task Role
    3. The task should include the
    4. Click
    5. Click
      View task definition

Testing the task

  1. Log into the AWS Management Console.
  2. Go to
    Services > ECS
  3. Click
    , then select one of your Fargate cluster.
  4. Click the
    tab, then click
    1. For
      Launch type
      , select
    2. For
      Task Definition
      , select your pre-defined task.
    3. Enter a
      Service name
    4. For
      Number of tasks
      , enter
    5. Click
      Next step
    6. Select a
      Cluster VPC
      , then click
      Next step
    7. For
      Service Auto Scaling
      , select
      Do not adjust the service’s desired count
      , then click
      Next step
    8. Review your settings, then click
      Create Service
  5. Validate the results.
    1. Click
      View Service
    2. When Last status is Running, your Fargate task is running.
    3. The containers are running.
  6. View the defender in the Prisma Cloud Console: Go to
    Manage > Defenders > Manage > Defenders
    and search the fargate task by adding the filters

Jenkins Fargate example

Passing the Fargate task definition to your Prisma Cloud Console’s API returns the Prisma Cloud protected Fargate task definition. Use this task definition to start Prisma Cloud protected Fargate containers. This example demonstrates using the Jenkins Pipeline build process to:
  • Call the Prisma Cloud Console’s API endpoint for Fargate task creation.
  • Pass the Fargate task definition to the API.
  • Capture the returned Prisma Cloud protected Fargate task definition.
  • Save the Prisma Cloud protected Fargate task definition within the Pipeline’s archive https://<jenkins>/job/<pipeline_name>/<job#>/artifact/tw_fargate.json
In this example, a simple task fargate.json and Jenkinsfile have been placed in a GitHub repository.
{ node { stage('Clone repository') { checkout scm } stage('Fargate Task call') { withCredentials([usernamePassword(credentialsId: 'twistlockDefenderManager', passwordVariable: 'TL_PASS', usernameVariable: 'TL_USER')]) { sh 'curl -s -k -u $TL_USER:$TL_PASS https://$TL_CONSOLE/api/v1/defenders/fargate.json?consoleaddr=$TL_CONSOLE -X POST -H "Content-Type:application/json" --data-binary "@fargate.json" | jq . > tw_fargate.json' sh 'cat tw_fargate.json' } } stage('Publish Function') { archiveArtifacts artifacts: 'tw_fargate.json'} } }
Code copied to clipboard
Unable to copy due to lack of browser support.
  1. Create an account in Prisma Cloud with the Defender Manager role.
  2. Create a Jenkins username/password credential for this account called
  3. The
    Jenkins global variable was defined when the Prisma Cloud Jenkins plugin was installed.
  4. Create a Jenkins Pipeline.
    1. Definition:
      Pipeline script from SCM
    2. SCM:
    3. Repository URL: <path to repository that contains both the Jenkinsfile and fargate.json>.
    4. Credentials: <credentials for repository>.
    5. Script path:
    6. Save.
  5. Run
    Build Now
  6. The tw_fagate.json file will be within the archive of this build https://<jenkins>/job/<pipeline_name>/<job#>/artifact/tw_fargate.json.

Recommended For You