One of the cool souvenirs I’ve accumulated in my career is a Ship It award for some of the authentication and encryption technologies in what was then called Red Dog but what you now know as Azure. Many of the other early Twistlock guys also worked on Azure, so we’re always happy to see it keep evolving. We’ve been there from the start of containers on Azure, like support for ACS (see this post on the official Azure Security blog), being a launch partner for ACR, and for more recent innovations like AKS and ACR quarantine. We were excited to learn about the new AKS virtual nodes feature and wanted to talk a little about how we provide runtime on that platform.

Breaking down Azure Container Instances

Azure Container Instances (ACI) are what we consider to be a ‘containers on demand’ platform in the Continuum of Cloud Native Topologies. Technologies like ACI simplify the developer experience by abstracting out nearly all of the underlying system level configuration required to launch and run containers. Unlike serverless/FaaS platforms, though, they do this while preserving the platform independence and ‘run anywhere’ nature of container images. Because ACI runs regular Docker images, Twistlock has always provided vulnerability management and compliance enforcement for the images you run there. However, because platforms like ACI intentionally constrain the privileges available at the host OS level, our approach for providing runtime defense is different than on a more classical container environment.

Platforms like ACI (and AWS Fargate) have 2 key differences from a security standpoint relative to these classical container deployments. First, they follow a single app:VM model. Specifically, unlike a classical container deployment model in which a given host may run tens or hundreds of containers for different apps, in ACI small, highly efficient VMs are used to isolate each container group deployment. This enables the portability of containers with the high security isolation provided by hypervisors. Second, ACI constrains access within the VM, by limiting the ability for processes to elevate or run with heightened privilege at the host OS level. This combination of factors means that the architectural model for these platforms needs to embed protection within the containers themselves, rather than be completely encapsulated within a peer container on the same host.

Note that AKS virtual nodes provides yet another nuanced requirement – even though you’re interacting with a Kubernetes cluster, AKS virtual nodes are provided via ACI, so while you can deploy Twistlock as a DaemonSet to all nodes in a typical AKS cluster, if you’re using virtual nodes, you’ll protect them using the approach described above for ACI.

Protecting ACI with Twistlock

For ACI or Fargate, we try to take all the work out of protection, especially for developers. We’ve made it really simple to embed Defender into your original, unaltered images, and you can do this via the product UI or API and can easily integrate the embedding into your CI/CD process. The embedding simply takes your existing Dockerfile, adds our Defender components, and then configures Defender to be the ENTRYPOINT for the image. Once Defender starts, it immediately then invokes your own app. This flow adds <5ms to the initial start time of your container and virtually no overhead during normal operating conditions while running. As the parent process, Defender has ‘admin-lite’ capabilities within the app, even though it does not (and cannot) run with heightened privilege from a host OS perspective. However, these capabilities are sufficient for Defender to learn what binaries are part of the original, genuine image and automatically block anything foreign, to allow / deny network egress based on DNS namespace, and other key security capabilities. Here’s a look at a simple Dockerfile, with the portions changed by our embedding highlighted:
FROM cdue/webconsole

RUN apt-get update && apt-get install -y net-tools

COPY aci_entrypoint.sh libtw.so defender /bin/tw/aci/
RUN chmod 0755 /bin/tw/aci

ENV DEFENDER_TYPE=aci
ENV WS_ADDRESS=wss://twistlock.contoso.com:8084
ENV INSTALL_BUNDLE=eyJjY…PSJ9

ENTRYPOINT [ “/bin/tw/aci/aci_entrypoint.sh”, “bash”, “-c” ]

CMD ["apache2-foreground" ]

Once running, these Defenders appear in the product alongside all others. Here’s an example of a simple environment with a Defender in a classic ACI node as well as one protecting an AKS virtual node:

Here’s a view of the default policy that automatically prevents any executables not part of the original image – no manual learning nor manually defined block list required:

Our Dockerfile example above used cdue’s image of the excellent Web-Console project. Below you can see me downloading a foreign binary into the container, attempting to run it, and Twistlock stopping it, all without a single manually defined rule or signature. While a simplistic example, this is a powerful scenario that illustrates protection from the most common first step taken in most real world attacks. Once an app is compromised, attackers almost invariably attempt to download toolkits for recon and expansion. Only allowing original, genuine binaries to run provides an elegant and powerful mitigation for that.

Back in Twistlock, you can see the results of these events:

Obviously, these events can also be sent to any of our supported alert providers, like email, Slack, JIRA, PagerDuty, or even generic webhook endpoints.

Probably the coolest part about our ACI and AKS virtual nodes support is how well integrated it is into the overall platform. You bring the images, we give you an automated and simple way to embed Defender in them, and then you have strong protection for them on ACI or AKS virtual nodes. The entire capability is just another part of our singular platform that protects you across the continuum of Azure cloud native services, from the VMs to self-host containers, to AKS, to ACI, to Azure Functions.

Get started with Twistlock today! Request an evaluation here.

← Back to All Posts Next Post →