As a large global cloud service provider, Amazon Web Services (AWS) has a global partner ecosystem (the AWS Partner Network, or APN) that continues to grow with many interesting Consulting and Technology partners. One space that is relatively new is container services. AWS announced Amazon EC2 Container Service (ECS) and Amazon EC2 container registry (ECR) in December 2015. As the security partner,  Twistlock integrates with both ECS and ECR to provide container security services to AWS customers.

This blog post provides an overview on how AWS users can leverage Twistlock technology with ECS and ECR to protect their containerized applications.

As a refresher, Twistlock provides an end to end security suite to secure containers from development to production. The Twistlock functionality includes vulnerability management, compliance, access control, and runtime defense.

Twistlock with ECR: If you use AWS EC2 Container Registry (ECR), Twistlock can scan your images stored in ECR to detect and help eradicate vulnerabilities and malware. In order to leverage Twistlock with ECR, an AWS user can configure ECR as one of the registries to be scanned via the Twistlock console. Once you configure it and share the ECR access credential via Twistlock’s secure portal, Twistlock will periodically scan all ECR images associated with that credential. You can also scan your images on demand, which you can initiate via the Twistlock console. A more in-depth blog on Twistlock with ECR can be found here. You can also watch an online demo here.

Note that configuring ECR for Twistlock is exactly the same as configuring other registries, regardless if it’s public or private. The scanning results are displayed in the central console. This way, a user can keep track of all his/her images regardless where they live. More specifically, Twistlock breaks down the image to understand the base layer, the app frameworks, all the way to the customer app on top. Maybe you are running an Apache image on Ubuntu with a custom Node.js application on top. Twistlock will build a bill of materials of the image and look for vulnerabilities and malware across all its layers.

Twistlock also provides an up-to-the-minute feed of vulnerability and threat data, called the Twistlock Intelligence Stream, that pulls from a wide range of providers, including open source projects, Twistlock research Labs, and commercial providers. The Intelligence Stream ensures you’re always monitoring your images and containers with up-to-date threat and vulnerability information.

Here is a more detailed screencast on the vulnerability management feature of Twistlock, which is what you would most likely use with Amazon EC2 Container Registry (ECR).


Twistlock with ECS: For ECS customers, ECS automatically handles your cluster management – there is no need to have your own cluster management infrastructure on AWS. To enable Twistlock on ECS is very simple, you would launch us as part of your cluster of container instances and ECS will automatically manage Twistlock’s deploying and scaling for you. All Twistlock functionality, including vulnerability management and runtime defense would work within ECS.

With ECS, runtime defense becomes really interesting. Twistlock runtime defense automatically learns what your images should do – from network, process, system calls, and file system perspectives – and detects anomalies and deviation of behavior in runtime. This capability also ties with ECR, where we would conduct image analysis as we detailed above. This helps us to build a predictive model of the container behavior.

For example, if you built a nginx image, Twistlock will model the nginx process, the storage partition, the network sockets, the network tree, and the syscalls the image should make in runtime. If a perpetrator compromises the nginx web service, say with a buffer overflow attack, Twistlock would see the anomalous system call as the result of the buffer overflow. And if the injected code tries to connect to another container in your environment that violates the networking model, Twistlock would see that as well and flag that as an anomaly. Lastly, if the attacker successfully spawns a shell, Twistlock’s process model would detect that an anomalous process, one that does not belong in the nginx process map, has been started and could block the container from running altogether.

Here is a more detailed screencast on the runtime defense feature of Twistlock.

 Twistlock with EC2 instances: If the customer is using classic AWS EC2 container service instances and elects to manage their container clusters with their own cluster management infrastructure, you would install Twistlock as you would with other software containers into your EC2 instances, and manage Twistlock with your own cluster management infrastructure. Again, all Twistlock functionality, including vulnerability management and runtime defense would work seamlessly.

One of the cool features of Twistlock is Compliance, where we implement container hardening practices and this is also the place a customer can specify custom organizational policies with respect to the secure operation of containerized applications. For example, one of the policies that you may want to enforce is that only images from pre-approved repositories are allowed to run in your AWS environment. In this case, Twistlock will cryptographically validate every image you try to run in the AWS environment to validate it is indeed from this trusted repository. Twistlock has many such built-in policies that a customer can use to harden their AWS environment. Or, the customer can use the XCCDF framework to specify a custom policy which Twistlock can parse and enforce automatically.

Here is a more detailed screen cast that shows the compliance capability of Twistlock.

Putting it together

Of course this blog post wouldn’t be complete without a CloudFormation template to let you try out Twistlock yourself. The template is located here. We used a base Ubuntu 16.04 image and the free Developer Edition of Twistlock deployed in a onebox configuration (Console and Defender installed on the same box). To deploy the CloudFormation template the only thing you need to do is providing an existing KeyPair and passing that as a parameter when you create a Stack.

When you finish the deployment you can now browse the Twistlock console. When you get to the console you will be brought to the licensing page, where you will enter the Developer Edition license key you can get from Twistlock ( Developer Edition is free forever for protecting up to 2 hosts.

After you have added the license, lets look at a demo scenario. First, let’s do some vulnerability management. The first scenario is to alert and the second scenario is actually blocking it.

In the Twistlock Console go to Defend-> Vulnerabilities-> Policy and create a new policy.

Set the Effect to Alert and check ID 46 (Image contains vulnerable package versions).

Click Save.

Now ssh to the host where you installed Twistlock to pull down and image.

An example image to pull down might be Ubuntu:trusty

Type “docker run ubuntu:trusty”

Then browse to Monitor -> Vulnerabilities in the Console to see the state of the image you just ran.

Take this a step further: change the policy action to Block and then run a docker pull of ubuntu:latest

NOTE in the screenshot below we are passing in docker –H :9998 –tls pull Ubuntu:latest. This is because the Twistlock Defender functions as a proxy so –H :9998 is telling the Docker client to connect to the Defender on port 9998. The –tls is passing in the authentication which comes from certificates which are installed in the .docker folder via the Twistlock console under Configure -> Access- Certificates. Just run the curl command there on the host to install the certificates.

Now let’s try some Runtime Defense.

From in the console in Defend-> Runtime -> Processes

  1. Select + Processes Rule, give the rule a name, set the Effect to “allow”, click Save.

From in the console go to Defend-> Runtime -> Network

  1. Select + Network Rule, give the rule a name, set the Effect to “allow”.
  2. Under Additional block list, add in
  3. Click Save.

Now just “docker exec” into the container and run, as an example, wget In this scenario the process sensor would pick up the wget but the network would pick up the attempt to browse to

If you are interested in learning more about Twistlock on AWS, read this AWS blog, or contact us via

What’s Next?

← Back to All Posts Next Post →