Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Conversational AI / SaaS Platform |
| Cloud Environment | AWS (primary), Azure, GCP |
| Workloads | Kubernetes (majority), Docker containers deployed directly on VMs |
| Code & CI | GitHub, Jenkins for CI |
| Existing Scanning | Periodic vulnerability assessment (VA) scans |
| Focus Area | Container Runtime Security (Kubernetes + Docker-on-VM) |
The Situation: Most Workloads on Kubernetes, But Not All
This platform runs most of its services on Kubernetes, but not everything. A meaningful share of workloads are Docker containers deployed directly on virtual machines — the pattern many teams reach for when a service does not warrant a full orchestration layer but still ships as a container. Their CI runs on Jenkins, and their vulnerability coverage came largely from periodic VA scans.
The specific question the team raised is one that a lot of container security tooling quietly sidesteps: do you do runtime security for a Docker container deployed directly on a VM — not orchestrated by Kubernetes? It is an honest question, because a great deal of container security is implicitly Kubernetes-shaped. Tools assume an orchestrator, a control plane, admission controllers, and pod-level context. A container running under docker run on an EC2 instance has none of that scaffolding — and often falls into a coverage blind spot as a result.
The Core Challenge
Container security coverage was uneven. The Kubernetes estate had some structure around it, but Docker containers running directly on VMs — and the runtime behavior of containers in general — were not continuously monitored. Periodic VA scans caught what existed at scan time; they did not watch what a running container actually did between scans.
Where the Gaps Were
1. The Gap Between the Image and the Running Container
Scanning an image tells you what vulnerabilities exist in the artifact. It does not tell you what the container does once it is running — whether it spawns unexpected processes, reaches out to unusual network destinations, mounts sensitive host paths, or runs with more privilege than it needs. For containers built in Jenkins and deployed to VMs, image-time checks alone leave the runtime unobserved.
2. Docker-on-VM Falling Outside Kubernetes-Shaped Tooling
Because much container tooling assumes Kubernetes, containers running directly on VMs often have no dedicated runtime coverage. They are not pods, they have no namespace, and they do not pass through an admission controller — so the very hooks many tools rely on simply are not there. The result is a class of workloads that are containerized but effectively unmonitored at runtime.
3. Periodic Scans Cannot See Runtime Behavior
VA scans are valuable point-in-time assessments, but a runtime threat — a compromised process inside a running container, a container reaching for credentials it should not touch — is a live event, not a static configuration. Between one scan and the next, the runtime is dark.
4. Two Deployment Models, No Single View
With most workloads on Kubernetes and some on Docker-on-VM, the team faced the prospect of two different security models for two deployment styles — more tools, more dashboards, and no unified picture of container risk across the estate.
The Cloudanix Approach: Runtime Coverage for Both Models
Cloudanix’s Workload Protection treats the container estate as one layer, covering both Kubernetes workloads and Docker containers running directly on VMs — with image scanning before deployment and runtime protection after.
Image Scanning Before Deployment
For containers built in Jenkins, Cloudanix scans images for OS-level and dependency vulnerabilities, insecure configuration (running as root, unnecessary capabilities), and image provenance — catching vulnerable artifacts before they reach a registry or a running host. This is the checkpoint that periodic VA scans do not provide as part of the build flow.
Runtime Protection for Running Containers
The image is only half the picture. Cloudanix’s container runtime security observes what containers actually do once running — unexpected process execution, anomalous network activity, privilege misuse, and sensitive host access — for both Kubernetes pods and standalone Docker containers on VMs. This directly answers the team’s question: runtime coverage is not limited to orchestrated workloads. A container running under Docker on an EC2 instance is monitored the same way a pod is.
One Model Across Kubernetes and Docker-on-VM
Rather than one tool for orchestrated workloads and another (or nothing) for Docker-on-VM, Cloudanix provides one view across both deployment styles. For a team splitting workloads between Kubernetes and direct-on-VM containers, this means container risk is visible in one place regardless of how a given service happens to be deployed.
Correlated With Host and Identity
On Cloudanix’s asset graph, a runtime finding in a container connects to the VM it runs on, the identity that VM assumes, and the network exposure around it. A suspicious process in a container on an internet-facing VM with an over-privileged role is a very different priority from the same process on an isolated internal host — and the graph makes that distinction visible.
The Outcome
The team gained continuous runtime coverage across both its Kubernetes estate and its Docker-on-VM workloads, with image scanning integrated into the build flow and runtime behavior observed after deployment — replacing a model where standalone containers and runtime activity were effectively unmonitored between periodic scans.
Key Results
✅ Runtime Coverage for Docker-on-VM: Not limited to orchestrated Kubernetes workloads ✅ Image + Runtime Together: Vulnerable artifacts caught before deploy, behavior watched after ✅ One Model for Two Deployment Styles: Kubernetes and Docker-on-VM in one view ✅ Beyond Point-in-Time Scans: Continuous runtime observation, not periodic snapshots ✅ Findings as Attack Paths: Runtime activity correlated with host, identity, and exposure
Running Containers Both On and Off Kubernetes?
If some of your containers run on Kubernetes and others run directly on VMs — and your runtime coverage stops at the orchestrator’s edge — Cloudanix covers both with one model.
Schedule a Demo to see runtime security across your container estate.
Related Resources
- What is CWPP?
- What is Container Security?
- Container Runtime Security and Its Importance
- What is Container Image Scanning?
- Importance of Kubernetes Security
- Container Security and Real-Time Visibility for Modern Cloud
- Consolidating VM, Container, Code, and Cloud Security for a Conversational-AI Platform
- Top 12 Container Security Best Practices
