1. Overview

RASP Defenders for Fargate monitor your tasks to ensure they execute as designed, protecting tasks from suspicious processes and outbound network connections.

RASP Defender policies let you define:

  • Process whitelists or blacklists. Enables verification of launched processes against policy.

  • Outgoing connections whitelists or blacklists. Enables verification of domain name resolution against policy for outgoing network connections.

Besides runtime policy, you can also configure the CNAF application firewall to protect front-end Fargate tasks.

2. Architecture

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

  • Mount the Twistlock sidecar container’s shared volume to gain access to the RASP Defender binaries.

  • Start the original entrypoint command under the control of RASP Defender.

RASP Defenders do not communicate directly with Console. All communication is proxied through the Twistlock sidecar container. The following diagram illustrates the setup:

install rasp defender fargate architecture

2.1. CNAF For Fargate

All the capabilities of standard CNAF 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 CNAF 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. CNAF for Fargate forwards the filtered traffic to your application port - unless an attack is detected and you chose Prevent in your CNAF for Fargate rule.

For more information on the type of attacks that Twistlock detects and prevents, see Twistlock CNAF.

2.2. Securing Fargate tasks

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

  1. Define your policy in Twistlock Console. By default, there are no rules in the RASP runtime policy. RASP Defenders dynamically retrieve policies from Console as they are updated. You can embed RASP 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.

3. Embed RASP Defender into Fargate tasks

Twistlock cleanly separates the code developers produce from the Fargate containers we protect. Developers don’t need to change their code to accomodate Twistlock. 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 Twistlock API to embed the Fargate Defender into your task definition.

Prerequisites

  • The task where you’re embedding RASP Defender can reach Console’s port 8084 over the network.

  • You have the task definition.

Your task definition must include matching entrypoint and cmd parameters from the Dockerfile(s) of the image(s) in your task. Because Twistlock does not see the actual images as part of the embedding flow, it depends on having these parameter present to reliably insert RASP 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.

Procedure

  1. Log into Twistlock Console.

  2. Go to Manage > Defenders > Deploy.

  3. In the first drop-down list, choose the name or IP address RASP 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 Names 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 Deploy tab.
    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.
  4. In the second drop-down list, choose the Defender type of RASP.

  5. Set the Deployment type to Fargate Task.

  6. 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.

  7. In AWS, create a new task definition using the new Twistlock protected task. If you already have an existing task definition, create a new revision.

Results

After running your task, view audits in Twistlock Console. Go to Monitor > Events, and select RASP Audits.