On-Demand Container Security 101

How to Protect Emerging Serverless Compute Platforms

What are on-demand containers?

It’s easier than ever to deploy applications using containers. Over the past year or so, new types of “turnkey” container services, such as AWS Fargate, Azure Container Instances, and Google Cloud Run, have debuted with the goal of allowing developers to deploy containerized applications without thinking much at all about the container infrastructure that hosts them. Solutions like these, which are sometimes called “on-demand containers” — are great for enabling easier access to the advantages of container-based app deployment.

However, they also create a big challenge from a security perspective. By removing much of the complexity required to deploy containers, they also place strict constraints on which tools you can use in conjunction with your containerized environment, and which ways you can customize it. Some also use container runtimes other than Docker’s, which can make them harder to monitor and analyze using external tools. The result is container-based deployments that are not fully compatible with third-party security tools.

Does that mean that security-conscious admins need to avoid on-demand container services? Fortunately, no. There are ways to secure these environments effectively, but they require a different approach than the one you would typically take for securing a stock Docker environment.

The on-demand container evolution

In Docker’s early days, using containers required you to set up your own hardware, or a stock virtual machine instance in the cloud, and install Docker on them manually.

Then, Containers-as-a-Service (or CaaS) offerings like AWS’s Elastic Container Service and Azure Containers began to appear. These solutions make container deployment easier by providing preconfigured infrastructure for hosting containers. However, they still give you a lot of flexibility in choosing exactly how to configure your containerized environment.

Does that mean that security-conscious admins need to avoid on-demand container services? Fortunately, no. There are ways to secure these environments effectively, but they require a different approach than the one you would typically take for securing a stock Docker environment.

Now, a new breed of container-deployment services has appeared in the form of on-demand containers. Again, AWS Fargate and Azure Container Instances are two examples. Pivotal Cloud Foundry Pivotal Application Service, which uses containers to deploy apps but doesn’t use the Docker runtime, is a third example.

Then, Containers-as-a-Service (or CaaS) offerings like AWS’s Elastic Container Service and Azure Containers began to appear. These solutions make container deployment easier by providing preconfigured infrastructure for hosting containers. However, they still give you a lot of flexibility in choosing exactly how to configure your containerized environment.

On-demand containers are designed to minimize the time and fuss required to deploy a containerized app. They provide completely preconfigured infrastructure and automatic orchestration. A user can simply select the container images they want to run, then deploy them.

How on-demand containers work with CaaS

To be clear, many vendors that are offering on-demand container services also offer CaaS solutions. You shouldn’t think of on-demand containers and CaaS as competitors; instead, they’re different solutions for different challenges. If you don’t need a lot of control over your container environment and just want to get your application up and running quickly, on-demand containers are the way to go. A traditional CaaS is a better choice for more complex containerized apps that require complicated configurations, and/or in situations where you think you can do a better job of managing your containers than a fully automated solution could.

Tradeoffs with on-demand containers

The necessary downside to on-demand containers is that they give end-users less control and flexibility than a traditional CaaS. In order to keep things simple, they remove virtually all configurability from the user’s perspective.

On-demand container services are also built using specific tools that are chosen by the vendor that offers the service. Your on-demand container service might not use the Docker runtime, or any OCI-compliant one. It might not provide a way for external tools to monitor your containerized app or inspect your configurations.

Security challenges for on-demand containers

From a security perspective, this can present a challenge. On-demand container services are designed to be secure, and you might be able to perform basic monitoring for them using monitoring tools supplied by the vendor. You can also always scan your container images before you deploy them into the service.

But in most cases, vendor-supplied monitoring tools and static image scanning fall far short of providing the security analysis you need to detect all potential vulnerabilities, especially those that could impact an app at runtime.

Securing on-demand containers with Runtime Application Self-Protection (RASP)

In order to protect cloud native applications running on-demand containers, organizations need to bake security into the application itself, rather than relying on a third-party tool or service to monitor the app independently.

This is why we’ve introduced RASP Defender to Twistlock. RASP Defender runs as part of your app, and provides the same security protections as Twistlock would provide when running as a third-party tool.

With this approach, all you have to do is include the tool within your app. Then, when you deploy the app using an on-demand container service, you’ll have all the benefits of third-party security monitoring, without the need to configure the environment, or spending time discovering a way to expose your app to an external tool.

And RASP Defender works with any container runtime. In fact, it even works with non-containerized apps. It works from the inside to regulate how the app behaves and to mitigate security problems — the way the app is packaged is not important.

BLOG

Runtime Application Self Protection: Protecting Your Apps Wherever They Run

Read now

Protect Your Cloud Native Applications with Twistlock

Twistlock integrates across the application lifecycle and secures your applications at runtime with runtime application self-protection (RASP) for your applications on AWS Fargate, Microsoft ACI, Google Cloud Run, Mesosphere DC/OS containerizers and Pivotal PAS.

  • Manage and prevent vulnerabilities from development to production. Twistlock integrates with the the CI process, at the registry, and in production to identify and prioritize vulnerabilities and risk in images.

  • Continuously monitor your repositories and blobstores. Twistlock automatically scans your image and code repositories so you always know you are deploying secure applications to your on-demand container platform of choice.

  • Powerful runtime protection with RASP. Twistlock RASP Defender runs as part of your application, and provides the same security protections as Twistlock would provide when running as a third-party tool.