Twistlock Platform

AWS Fargate Security: Runtime Defense with Twistlock 2.5

This technical deep dive highlights key capabilities released as part of Twistlock 2.5. To learn more about what’s included with Twistlock 2.5, check out our full release blog post.

Cloud native deployment architectures are proving to be the norm in today’s enterprises. Companies are utilizing new technologies such as Docker, Amazon ECS, and Kubernetes to help deploy applications in the cloud effortlessly. These technologies are new and evolving quickly, requiring organizations to continually learn how they can better manage and secure their applications running on these new stacks.

Many of the cloud providers have recognized the rapid transition to the cloud and have developed emerging technologies that remove the need to manage underlying infrastructure to allow rapid deployment of new applications. One of the most commonly discussed technologies is AWS Fargate.

With the release of Twistlock 2.5, Twistlock now provides runtime defense for applications running on AWS Fargate. In this blog, I’ll share benefits of running applications on Fargate, discuss security challenges that you should be aware of, and demo Twistlock protection for your Fargate applications.

What is AWS Fargate?

Fargate is a new service offered by Amazon that enables you to run containers by deploying tasks without having to worry about the underlying infrastructure. Fargate is powered by Amazon ECS, so deploying tasks is straightforward and a lot of the terminology will feel familiar to ECS users. Not only does Fargate eliminate the need to manage and secure the cluster virtual machines, but you are also only deploying infrastructure to support the resource requirements of the applications running. In a traditional cluster deployment the resources are “always available” which means unless you are fully utilizing your cluster’s resources you are paying for capacity that you are not leveraging. With a Fargate task you allocate CPU and memory shares while configuring the tasks. Applications deployed on Fargate can save you time, man power, and money.

What are some of the security challenges?

Deploying applications to a CaaS environment comes with its own set of challenges. The main challenge comes from the fact that you do not have access to the host virtual machine, which makes installing a traditional security agent directly on the host impossible. Even though you cannot install an agent, you still have to provide security for the applications. There are two main approaches to securing these applications: embedding the agent or loading the agent at runtime. Let’s take a quick look at each approach.

Embedding an agent

Embedding an agent directly allows you to include everything you need in the container image, which makes it directly available when the application is running. Because the image has all the layers embedded during the build, there is no need to install additional software to secure the application. Security comes baked in to the application wherever it is deployed, but this approach has some drawbacks.

For example, anyone can modify the image and remove the security layers completely, potentially allowing someone to deploy the application with no security at all. In order to enforce that containers have the proper security model applied, you will have have to employ a “trusted images” deployment approach. Trusted images allow you to whitelist image based on the image ID, origin, or base layer, thereby ensuring that only trusted or authorized images get deployed.

Loading the agent at runtime

The preferred way of deploying security for Fargate applications, detailed in this second approach, involves loading the agent at runtime from a sidecar container. The sidecar approach does not require modifying any of the application images as the security capabilities, including the model, are mounted from the sidecar. The helps keep a separation between the application itself and security of the application. When an image is deployed the container is augmented with security by injecting the agent at runtime. This helps you ensure that all applications that are deployed run securely wherever they are deployed and the developers are not responsible for embedding security or even defining the security profiles themselves.

Runtime defense for Fargate applications

Let’s walk through an example of protecting a very exploitable container with the Twistlock Fargate Defender.

Create your cluster

  1. Log in to your AWS control panel and under Services choose Elastic Container Service.
  2. Click “Create Cluster” and choose the Networking only cluster template, then click next.

  3. Choose a cluster name. I chose “fargate-blog” for this example.
  4. Check the Create VPC and leave the default values.
  5. Click “Create”

Let’s deploy something to Fargate!

I’ll start with a sample task that will make the application extremely vulnerable. It will start netcat listening on port 80 which will allow us to run arbitrary commands on the container!

{
  "requiresCompatibilities": [
      "FARGATE"
  ],
  "containerDefinitions": [
    {
      "entryPoint": null,
      "portMappings": [
        {
          "hostPort": 80,
          "protocol": "tcp",
          "containerPort": 80
        }
      ],
      "command": [
        "nc",
        "-l",
        "-p",
        "80",
        "-e",
        "/bin/sh"
      ],
      "image": "alpine:latest",
      "name": "twistlock-fargate-task"
    }
  ],
  "family": "twistlock-fargate-task",
  "volumes": [],
  "networkMode": "awsvpc",
  "memory": "512",
  "cpu": "256"
}

Define a security policy in Console

The example I will use here enables process level protection inside the Fargate container. In order to do this we must first define a security policy that will limit which processes are allowed to run inside the container. This would generally be limited to the binaries found in the original image, so we will use the the default values in this policy.

Create a new Task definition to run our exploitable container

  1. In your AWS console navigate to Services -> Elastic Container Service.
  2. Click Task Definitions.
  3. Click Create new Task Definition.
  4. Choose the FARGATE task type and click next.

  5. Scroll to the bottom of the page and choose Configure via JSON.
  6. Leave this open in your browser for now, we are going to paste a JSON generated by Twistlock in the next step.

Embed the Defender

One of the keys to the Twistlock approach removes the need to edit the task JSON yourself. Manual editing of the JSON requires intimate knowledge of the data structures and introduces potential for errors. To help with this, Twistlock allows you to automatically embed the Fargate Defender in the task definition without any manual editing.

Just paste your task definition on the left and click “Generate Protected Task” from within the Console.

Click the Copy button and paste this to the “Configure via JSON” window opened in the previous step and click “Save”.

You will notice there are two containers now. One is your Fargate Task’s container and the second is an ephemeral Twistlock container that will be used to load the Defender.


Click create.

Now let’s deploy and test!

  1. Navigate back to Services -> Elastic Container Service and select your cluster.
  2. Click the Tasks tab.
  3. Click Run new Task.
  4. Select the FARGATE launch type.
  5. Select the Task Definition: twistlock-fargate-task:1
  6. Choose a Subnet.
  7. Set Auto-assign public IP to enabled or you will have problems pulling the images.
  8. Click Run Task.
  9. After running the task, click the uuid of the task in the task table.

Note the Status. Once the twistlock-fargate-task container is RUNNING, you can connect to the external IP addressing on port 80

Note that the Twistlock Defender task is STOPPED. It only lives for a short time during the startup of your task.

An example attack on our Fargate application

The example attack below will demonstrate how Twistlock can prevent attacks on a running Fargate application:

  1. Connect to the running container using:
    nc < Public IP Address > 80

  2. Run a shell
    /bin/ash 2>&1

  3. Run an allowed command:

  4. Now let’s try to install a package that might further our attack.
    install curl

As you can see, the Twistlock Fargate Defender blocks the attack from proceeding by showing “Permission denied”. The process level protection will help protect you from attackers spawning processes that would further their attack. It can protect you from the side effects of known CVEs as well as unknown attacks.

Conclusion

Companies are rapidly adopting platforms like AWS Fargate and with that adoption comes new opportunities as well as challenges. Deciding which platforms are right for your application, and deciding how to go about securing your workloads are questions most enterprises are trying to answer.

Twistlock’s innovative approach to cloud native security pushes the boundaries of what is possible and allows you to protect yourself across not only the entire lifecycle, but your entire infrastructure from VMs to containers to serverless. To learn more about running applications on AWS Fargate, check out our recent blog AWS Fargate 101.

← Back to All Posts Next Post →
Twistlock Platform

AWS Fargate Security: Runtime Defense with Twistlock 2.5

Cloud native deployment architectures are proving to be the norm in today’s enterprises. Companies are utilizing new technologies such as Docker, Amazon ECS, and Kubernetes to help deploy applications in the cloud effortlessly. These technologies are new and evolving quickly, requiring organizations to continually learn how they can better manage and secure their applications running on these new stacks.

Many of the cloud providers have recognized the rapid transition to the cloud and have developed emerging technologies that remove the need to manage underlying infrastructure to allow rapid deployment of new applications. One of the most commonly discussed technologies is AWS Fargate.

With the release of Twistlock 2.5, Twistlock now provides runtime defense for applications running on AWS Fargate. In this blog, I’ll share benefits of running applications on Fargate, discuss security challenges that you should be aware of, and demo Twistlock protection for your Fargate applications.

What is AWS Fargate?

Fargate is a new service offered by Amazon that enables you to run containers by deploying tasks without having to worry about the underlying infrastructure. Fargate is powered by Amazon ECS, so deploying tasks is straightforward and a lot of the terminology will feel familiar to ECS users. Not only does Fargate eliminate the need to manage and secure the cluster virtual machines, but you are also only deploying infrastructure to support the resource requirements of the applications running. In a traditional cluster deployment the resources are “always available” which means unless you are fully utilizing your cluster’s resources you are paying for capacity that you are not leveraging. With a Fargate task you allocate CPU and memory shares while configuring the tasks. Applications deployed on Fargate can save you time, man power, and money.

What are some of the security challenges?

Deploying applications to a CaaS environment comes with its own set of challenges. The main challenge comes from the fact that you do not have access to the host virtual machine, which makes installing a traditional security agent directly on the host impossible. Even though you cannot install an agent, you still have to provide security for the applications. There are two main approaches to securing these applications: embedding the agent or loading the agent at runtime. Let’s take a quick look at each approach.

Embedding an agent

Embedding an agent directly allows you to include everything you need in the container image, which makes it directly available when the application is running. Because the image has all the layers embedded during the build, there is no need to install additional software to secure the application. Security comes baked in to the application wherever it is deployed, but this approach has some drawbacks.

For example, anyone can modify the image and remove the security layers completely, potentially allowing someone to deploy the application with no security at all. In order to enforce that containers have the proper security model applied, you will have have to employ a “trusted images” deployment approach. Trusted images allow you to whitelist image based on the image ID, origin, or base layer, thereby ensuring that only trusted or authorized images get deployed.

Loading the agent at runtime

The preferred way of deploying security for Fargate applications, detailed in this second approach, involves loading the agent at runtime from a sidecar container. The sidecar approach does not require modifying any of the application images as the security capabilities, including the model, are mounted from the sidecar. The helps keep a separation between the application itself and security of the application. When an image is deployed the container is augmented with security by injecting the agent at runtime. This helps you ensure that all applications that are deployed run securely wherever they are deployed and the developers are not responsible for embedding security or even defining the security profiles themselves.

Runtime defense for Fargate applications

Let’s walk through an example of protecting a very exploitable container with the Twistlock Fargate Defender.

Create your cluster

  1. Log in to your AWS control panel and under Services choose Elastic Container Service.
  2. Click “Create Cluster” and choose the Networking only cluster template, then click next.

  3. Choose a cluster name. I chose “fargate-blog” for this example.
  4. Check the Create VPC and leave the default values.
  5. Click “Create”

Let’s deploy something to Fargate!

I’ll start with a sample task that will make the application extremely vulnerable. It will start netcat listening on port 80 which will allow us to run arbitrary commands on the container!

{
  "requiresCompatibilities": [
      "FARGATE"
  ],
  "containerDefinitions": [
    {
      "entryPoint": null,
      "portMappings": [
        {
          "hostPort": 80,
          "protocol": "tcp",
          "containerPort": 80
        }
      ],
      "command": [
        "nc",
        "-l",
        "-p",
        "80",
        "-e",
        "/bin/sh"
      ],
      "image": "alpine:latest",
      "name": "twistlock-fargate-task"
    }
  ],
  "family": "twistlock-fargate-task",
  "volumes": [],
  "networkMode": "awsvpc",
  "memory": "512",
  "cpu": "256"
}

Define a security policy in Console

The example I will use here enables process level protection inside the Fargate container. In order to do this we must first define a security policy that will limit which processes are allowed to run inside the container. This would generally be limited to the binaries found in the original image, so we will use the the default values in this policy.

Create a new Task definition to run our exploitable container

  1. In your AWS console navigate to Services -> Elastic Container Service.
  2. Click Task Definitions.
  3. Click Create new Task Definition.
  4. Choose the FARGATE task type and click next.

  5. Scroll to the bottom of the page and choose Configure via JSON.
  6. Leave this open in your browser for now, we are going to paste a JSON generated by Twistlock in the next step.

Embed the Defender

One of the keys to the Twistlock approach removes the need to edit the task JSON yourself. Manual editing of the JSON requires intimate knowledge of the data structures and introduces potential for errors. To help with this, Twistlock allows you to automatically embed the Fargate Defender in the task definition without any manual editing.

Just paste your task definition on the left and click “Generate Protected Task” from within the Console.

Click the Copy button and paste this to the “Configure via JSON” window opened in the previous step and click “Save”.

You will notice there are two containers now. One is your Fargate Task’s container and the second is an ephemeral Twistlock container that will be used to load the Defender.


Click create.

Now let’s deploy and test!

  1. Navigate back to Services -> Elastic Container Service and select your cluster.
  2. Click the Tasks tab.
  3. Click Run new Task.
  4. Select the FARGATE launch type.
  5. Select the Task Definition: twistlock-fargate-task:1
  6. Choose a Subnet.
  7. Set Auto-assign public IP to enabled or you will have problems pulling the images.
  8. Click Run Task.
  9. After running the task, click the uuid of the task in the task table.

Note the Status. Once the twistlock-fargate-task container is RUNNING, you can connect to the external IP addressing on port 80

Note that the Twistlock Defender task is STOPPED. It only lives for a short time during the startup of your task.

An example attack on our Fargate application

The example attack below will demonstrate how Twistlock can prevent attacks on a running Fargate application:

  1. Connect to the running container using:
    nc < Public IP Address > 80

  2. Run a shell
    /bin/ash 2>&1

  3. Run an allowed command:

  4. Now let’s try to install a package that might further our attack.
    install curl

As you can see, the Twistlock Fargate Defender blocks the attack from proceeding by showing “Permission denied”. The process level protection will help protect you from attackers spawning processes that would further their attack. It can protect you from the side effects of known CVEs as well as unknown attacks.

Conclusion

Companies are rapidly adopting platforms like AWS Fargate and with that adoption comes new opportunities as well as challenges. Deciding which platforms are right for your application, and deciding how to go about securing your workloads are questions most enterprises are trying to answer.

Twistlock’s innovative approach to cloud native security pushes the boundaries of what is possible and allows you to protect yourself across not only the entire lifecycle, but your entire infrastructure from VMs to containers to serverless. To learn more about running applications on AWS Fargate, check out our recent blog AWS Fargate 101.

← Back to All Posts Next Post →