CaaS: Container as a Service Explained

Many organizations are moving toward containerization to help with application portability, efficiency, agility, and even security. The size and complexity of modern applications warrants a new approach, which abstracts the application itself from the underlying infrastructure. Containers as a service (CaaS) are cloud-based services that help make the management and deployment of container-based applications even easier.

While container security is an ongoing challenge for many teams, the right solutions in your DevSecOps toolchain can help secure both the container images and the software packaged up inside. First, let’s learn more about containers as a service.

Containers as a Service (CaaS) explained

Using CaaS, developers can automate container hosting and deployment, without worrying about managing the underlying infrastructure. CaaS is often independent of the code stack or programming language, which makes containers easier to deploy across a multi-cloud environment.

Benefits of using CaaS for DevSecOps

For DevSecOps teams, CaaS can help accelerate the time to develop secure applications and ship them into production. By reducing some of the bottlenecks that come with infrastructure configuration and management, CaaS can make it easier to deploy, manage, and scale container-based applications.

A containerized application is virtually isolated from other containers in the environment, which makes it harder for malicious actors to move laterally across an attack surface. Even so, there are many important container security implications to consider. As the number of containerized workloads grows, it’s important to adopt a container security solution that not only identifies vulnerabilities via container scanning, but also provides an intuitive way for developers to fix them.

Security considerations for CaaS

While a container as a service architecture abstracts away the underlying infrastructure control plane (in this case, a container orchestrator), security issues in container images, or the components that eventually run the application, are still the responsibility of the user. Since CaaS is typically provided as part of a wider IaaS platform (such as AWS, GCP or Azure), understanding the security implications of the underlying platform is also a key consideration.

In a container deployment, the container image needs to be well-constructed, following security guidelines to eliminate any potential issues. Security problems packed into the container image increase the risk and potential severity of issues that will happen in production. To that end, it’s important to monitor production, as well. Even the best images with no vulnerabilities and no elevated privileges do not absolve the team from monitoring the things going on in production.

Since containers combine operating system elements with application code, the responsibility to maintain the operating system components and packages shifts to developers and DevOps teams. This shift in responsibility, combined with the fact that containers can be updated and deployed in seconds, requires a new security methodology.

CaaS vs. PaaS vs. IaaS vs. FaaS

The sheer number of acronyms in the cloud services world can be overwhelming. All of these services are designed to abstract away the complexity that comes with managing infrastructure. While we’ve covered that CaaS simplifies container development and deployment (often as a part of an IaaS platform), let’s break down other key acronyms around cloud services.

PaaS

A platform as a service (PaaS) is a complete development and deployment environment for the cloud. Cloud service providers offer PaaS platforms that include infrastructure, middleware, development tools, analytics services, database management systems, and more. A PaaS supports the entire software development lifecycle (SDLC), including building, testing, deploying, managing, and updating.

IaaS

An infrastructure as a service (IaaS) platform is more lightweight than a PaaS. These cloud computing services offer compute, storage, and networking resources on demand. The infrastructure remains fully managed by a cloud service provider, and can automatically scale up or down depending on the user’s requirements.

FaaS

Just as CaaS is specific to container deployments, functions as a service (FaaS) are specific to microservices deployments where users need to run specific application components without managing servers. A subset of serverless infrastructure, FaaS focuses on event-driven computing models where application code, or containers, run in response to a specific event or request.

CaaS providers

While many different cloud services vendors offer CaaS platforms, here are three of the most widely used container as a service providers: Amazon, Google, and Microsoft. Team preference may depend upon the cloud environment they’re most accustomed to using. Developers using CaaS platforms should still be mindful of how they build their container images and what’s included in those images, and can use tools such as Snyk Container to scan their Dockerfiles in SCM, and container images within registries or CI/CD pipelines to make sure they’re built upon a secure base image and that application composition is secure before deployment.

Amazon Elastic Container Service (ECS)

This AWS container as a service offering is a fully managed container orchestration service that makes it easy to deploy, manage, and scale containerized applications. Using Amazon ECS, developers can launch containers across the cloud using their preferred continuous integration and delivery (CI/CD) and automation tools. These services eliminate the need to configure and manage the infrastructure control plane, nodes, and instances.

Google Cloud Run

This Google container as a service platform helps teams develop and deploy scalable containerized applications on a fully managed serverless platform. Google Cloud Run allows developers to use their preferred programming language, libraries, or binaries. Like ECS, Google Cloud Run abstracts away infrastructure management by automatically scaling container workloads up and down.

Microsoft Azure Container Instances (ACI)

Similar to both Amazon and Google’s offerings, Microsoft’s container as a service platform is a fully managed service. Teams can provision additional compute resources for demanding workloads with a single command, using ACI to elastically burst Azure Kubernetes Clusters as traffic surges. ACI also provides hypervisor isolation for each container group to ensure containers run in isolation without sharing a kernel.

Container orchestration

Many teams ask whether a container orchestration service (such as Kubernetes) is sufficient, or if they need a CaaS. While a CaaS platform could be considered a container orchestration solution, the fully managed nature of a CaaS generally makes it a simpler option for getting started using quickly. A CaaS is generally suitable for a wide variety of workloads and with less of a learning curve than Kubernetes.

The trade-off is that Kubernetes, due to its open source nature, is generally considered more portable. One can typically take a workload running on one Kubernetes distribution, and deploy it as-is, or with only a few minor changes, to another Kubernetes distribution. Kubernetes includes advanced capabilities that may or may not be available in a CaaS, like service discovery and load balancing, orchestrating storage, self-healing for Kubernetes clusters, secrets, configuration management, and more.

Teams could also explore the option of using Kubernetes as a service (KaaS) options, such as Amazon Elastic Kubernetes Service (EKS), Google Kubernetes Engine (GKE), and Azure Kubernetes Service (AKS), which serve as an in between step from Kubernetes to full CaaS, giving developers more tools for container orchestration while keeping their project open source.

Using Snyk Container to monitor your CaaS deployments

Container and Kubernetes security remains an ongoing challenge for many teams because the tools aren’t designed to be user-friendly for developers and DevOps teams. It’s critical to secure running workloads to reduce blast radius by eliminating security vulnerabilities in your application code, dependencies and containers.

Many container security issues relate back to code of some sort, including applications, container build files or workload configurations. The reason why many container scanning tools fall short is because they simply provide a list of vulnerabilities and issues, without equipping teams to know how to fix them. What’s more, many developers lack the knowledge to mitigate the security issues defined by these tools.

Snyk Container solves these challenges by not only monitoring CaaS deployments, but also helping developers quickly fix security issues. Snyk Container provides direct guidance to developers to fix container issues, starting with base image recommendations. In addition, it can automate fix pull requests (PRs) for containers, and detect Dockerfiles straight from Git repos.

This approach to developer-first container security makes security part of the team’s everyday thinking and build processes. Snyk Container can be utilized directly on the desktop, with the Snyk CLI or Docker Desktop. In addition, it integrates with source code managers, CI/CD tools, container registries, and Kubernetes to scan workloads as they’re deployed or updated in clusters.

When their original solution for container security became increasingly challenging to manage and upgrade, AI powered search company Coveo, turned to Snyk.  Using one simple, developer-friendly tool that would also secure container images appealed to Coveo.

“Snyk offers an easy-to-use SaaS service…  We needed a reliable solution to validate container images before moving to production, and Snyk is helping us do this in a simple way.”

Jean Phillipe - Coveo

Visit our Security Resources page to learn about how Snyk can help developers create high-quality, secure code.