Containers-as-a-Service (CaaS) Security 101

What CaaS Means, How to Manage It, and How to Secure It

CaaS basics

There are containers. And there is Containers-as-a-Service, or CaaS.

What’s the difference between plain-old containers and CaaS? For that matter, what’s the difference between Kubernetes-as-a-Service and CaaS? How do strategies for deploying or managing containers and CaaS vary? And which special security considerations should you take into account when using CaaS?

Keep reading for answers to these questions and more. Below, we define what CaaS is and cover the essentials of managing and securing CaaS.

What is Containers-as-a-Service (CaaS)?

CaaS is what it sounds like: It’s containers delivered as a service, typically, though not necessarily, as we’ll see below, using cloud-based infrastructure.

CaaS differs from other types of container deployments because CaaS is designed to minimize the amount of setup and management work required by DevOps teams or system admins. With CaaS, you typically need only to create an account, sign in and start deploying containers.

In order to understand CaaS fully, it’s important to wrap your head around a few key facts:

CaaS architecture: Like SaaS or IaaS, CaaS is simply an architectural model. It’s not a specific product or implementation of containerized infrastructure. There are lots of CaaS vendors and services available, such as ECS on the AWS cloud and AKS on Azure.

Platforms may provide inherent tooling: The exact tooling that comprises, and the extent to which you can pick and choose which tools to use on with CaaS, varies from one CaaS platform to another. Some CaaS platforms only give you one choice of container orchestrator or registry, for example, while others let you use multiple ones.

Where you can run CaaS: While most CaaS implementations are hosted in public clouds, some CaaS platforms, like Red Hat OpenShift, can be deployed on-premises. It’s thus wrong to think of CaaS as a cloud-only type of technology.

CaaS vs. Kubernetes-as-a-Service

Originally, CaaS architecture was conceived as a way to simplify the deployment of Docker containers using any type of orchestrator. However, as Kubernetes has emerged over the past few years as the leading container orchestration tool, some CaaS platforms (such as Azure AKS, which is short for “Azure Kubernetes Service”) have started orienting themselves around Kubernetes.

The terms “Kubernetes-as-a-Service” or “Managed Kubernetes” have consequently come into vogue, and it’s becoming increasingly common to hear these terms used to describe what was once called CaaS.

Is there a difference between CaaS and Kubernetes-as-a-Service? There might be some room for debate regarding that question. But we think it’s most accurate to think of Kubernetes-as-a-Service as basically a subcategory of CaaS. Any CaaS platform that uses Kubernetes as its default orchestrator could be called a Kubernetes-as-a-Service platform as well as a CaaS platform.

How much does CaaS require me to manage?

Although CaaS minimizes the setup and management work required to deploy containers, it’s important to note that CaaS does not eliminate that work entirely. The extent to which CaaS is hands-on varies from one platform to another, but at a minimum, users can expect to assume primary responsibility for:

1. Monitoring the CaaS environment for performance and availability.

2. Setting appropriate permissions to control access to the CaaS for security and compliance reasons.

3. Ensuring that the container images deployed on the CaaS are reliable. CaaS can’t make up for poorly written code or container image problems.

4. Monitoring CaaS for security intrusions. Your CaaS also can’t stop attackers for you.

Again, the exact management strategy you use for CaaS will vary depending on which features of the CaaS you are using and how much of the management work the CaaS automates for you. But the bottom line on this point is that you should not think of CaaS as a set-it-and-forget-it way to deploy containers. Users still bear primary responsibility for monitoring and securing their containers.

CaaS security considerations

Here are the main things you should be thinking about with regard to security when you are selecting and using CaaS:

CaaS differs from other types of container deployments because CaaS is designed to minimize the amount of setup and management work required by DevOps teams or system admins. With CaaS, you typically need only to create an account, sign in and start deploying containers.

Your CaaS is only as secure as the operating system that hosts it: Thus, you want to think about the extent to which the host operating system is hardened out of the box, and which level of control you will have to harden it further. This can vary greatly depending on whether you are using an on-premises CaaS, in which case you have pretty much full control over the host operating system, or a locked-down, cloud-based service, which typically gives you little access to the host system.

Access-control systems, like IAM on AWS, are critical tools for helping to secure a cloud-based CaaS: You can use these tools to restrict network access to your CaaS, as well as lock down storage resources that your CaaS might use.

Container-aware security tools are essential: Although some CaaS platforms come with basic monitoring tools, or can be monitored using a cloud vendor’s tool like CloudWatch, these tools don’t provide the level of insight you need to monitor fully for security risks and vulnerabilities. You should use additional container-aware security tools to check for vulnerabilities inside container images and monitor your runtime environment.

Don’t forget updates: Keeping your CaaS up-to-date is critical for making sure it is patched against known security flaws. This is easy in the cloud, where your CaaS will usually be updated automatically for you. If you deploy CaaS on-premises, however, you’ll want to make sure it is kept up-to-date, either by enabling automatic updates or having a process in place to ensure that you update it regularly, especially when security vulnerabilities are disclosed.

Understand how CaaS fits into your overall container strategy: CaaS platforms make it much easier in many respects to use containers. But they are not a replacement for human admins, and they don’t relieve you of the need to secure your containerized applications and environments. CaaS, or Kubernetes-as-a-Service, can help organizations implement an effective container strategy, but organizations need to keep in mind that management and security responsibilities will remain in your hands to a significant extent.


The Ultimate Guide to Container Security

Read now

Full Stack, Full Lifecycle Container Security with Twistlock

Twistlock provides full lifecycle, full stack container security for any platform and public cloud provider — ensuring you can deploy containers and Kubernetes fearlessly at scale.

  • 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 hosts, containers, and images.

  • Achieve and enforce compliance. Implement the Docker, Kubernetes, and Linux CIS Benchmarks, and leverage templates for HIPAA, GDPR, PCI and NIST SP 800-190. Compliance is integrated into CI / CD, so users can create thresholds to alert or block code as it is built or deployed as well as in production environments.

  • Defense-in-depth unmatched. Protect your running applications with layer 3 and layer 7 cloud native firewalls, powerful runtime defense, and access control — providing defense in depth to prevent next generation attacks.