What is container as a service (CaaS) and who secures what?

Container as a service (CaaS) is a cloud service that runs and manages containers for you, including the orchestration layer, so you deploy images instead of managing servers and clusters. It sits between infrastructure and platform services. The provider runs the platform. You still own the image, configuration and access.

Where does CaaS fit in the cloud models?

NIST SP 800-145 defines three service models. In IaaS you control operating systems and above. In PaaS you deploy applications onto provider tools. In SaaS you use the provider's application. CaaS is not one of NIST's named models. It is an industry label for something in the middle: you bring a container image, the provider handles scheduling, scaling and the machines underneath.

Because the label is informal, two "CaaS" offers can split responsibility differently. Read each one.

What does NIST say about container risk?

NIST SP 800-190, the application container security guide, organizes risks by layer: images, registries, orchestrators, containers and the host operating system. Its table of contents names concerns like stale images in registries, insufficient authentication and authorization restrictions, unbounded administrative access in orchestrators and unauthorized access to the orchestrator. With CaaS, the provider takes over some layers, such as the host and the orchestrator. You keep the image and registry risks and how your containers are configured.

Who secures what?

A reasonable starting point, to confirm against your provider's documentation:

• Physical and host: the provider.
• Orchestrator control plane: the provider runs it. You control access and settings.
• Container runtime isolation: mostly the provider. You control configuration.
• Image contents and dependencies: you.
• Secrets inside the app: you.
• Network rules and exposure: shared, and the rules you set are yours.
• Identity and permissions: shared, and the roles you grant are yours.

A constructed example

A team deploys a web service to a CaaS offering. The image was built a year ago on an old base layer with a known flaw in a bundled library. The provider patches the host and orchestrator regularly, yet the flaw remains, because it sits in the image, which the team owns. The fix is to rebuild images on a schedule and scan them before deployment.

What are the common mistakes?

• Running containers as root when not needed.
• Pulling images by a floating tag such as latest, so what runs is not what was tested.
• Putting secrets in image layers or plain environment variables.
• Giving the service a broad cloud role because it was quick.
• Leaving the service open to the internet by default.

How does it differ from running Kubernetes yourself?

When you run an orchestrator yourself, you also own its control plane, upgrades, node patching and access settings, which are large areas of risk in the NIST container guide. A CaaS offering moves most of that to the provider. In return you accept the provider's limits: fewer options, its release schedule and its logging choices.

Check how cluster or service level logs reach you, since the control plane is theirs but the investigation is yours.

How to check or apply this

1. Get the provider's responsibility split in writing for your service.
2. Build images from a small, maintained base and rebuild on a schedule.
3. Scan images and dependencies in your pipeline, and block on serious findings that are actually reachable.
4. Pin images by digest.
5. Run as a non-root user with a read only filesystem where possible.
6. Give each service its own narrow role.
7. Store secrets in a secrets service, not in the image.
8. Send container and platform logs to central monitoring.

Quick check

Sources

• NIST SP 800-145, The NIST Definition of Cloud Computing
• NIST SP 800-190, Application Container Security Guide

Last reviewed: 18 October 2026.