Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Healthcare (fertility / IVF) |
| Cloud Environment | AWS |
| Current Workloads | Docker containers on EC2 |
| Migration Target | Kubernetes (EKS), planned within the near term |
| Code & CI/CD | GitHub, GitHub Actions |
| IAM Profile | 10–15 users with AWS console access |
| Team | CISO-led, no dedicated security engineering |
| Code Origin | Partner-developed applications + AI-generated code (Cursor/GPT) |
| Cloudanix Scope | CSPM, CWPP, CIEM, Attack Path — carried from EC2 to Kubernetes |
The Situation: The Migration That Usually Resets Your Security Posture
The provider had a clear infrastructure plan: move from Docker-on-EC2 to Kubernetes within the near term. That plan is common, sensible, and, from a security standpoint, quietly dangerous, because for most teams a platform migration means starting the security work over.
The reason is structural. Tooling chosen for EC2 frequently does not cover Kubernetes with the same depth, so teams reach the migration and discover their posture scanning, their runtime protection, and their identity analysis all need to be re-evaluated for the new environment. The migration becomes a re-tooling project layered on top of an already risky platform change. During that window, the period when the team is learning a new orchestration layer and re-establishing controls, is exactly when security coverage tends to thin out.
This provider was especially exposed to that risk. The applications being migrated were built by an external partner and, more recently, by AI coding assistants, code the team did not fully understand on EC2 and would understand no better on Kubernetes. A lean, CISO-led team could not afford a migration that dropped their visibility at the worst possible moment.
The requirement, then, was continuity: the security posture established on EC2 today should carry forward into Kubernetes without a second tooling decision and without a coverage gap during the transition.
The Priority: Don’t Re-Tool at the Migration
The team’s goal was not to add Kubernetes security as a separate future project. It was to ensure that whatever they stood up on EC2 now would simply extend to EKS when they migrated, same platform, same graph, same operating model. This is where a unified CNAPP approach differs from assembling point tools per platform: the asset model is designed to absorb a new runtime rather than be replaced by it.
Where the Gaps Were
1. EC2-Specific Tooling Doesn’t Automatically Cover Kubernetes
A great deal of cloud security tooling treats Kubernetes security as a distinct problem with distinct tools. Teams that secure EC2 well often find their coverage does not translate, EKS introduces pods, RBAC, service accounts, network policies, and admission control, none of which exist on plain EC2. Without a platform that treats both as first-class citizens on one graph, the migration forces a fresh evaluation.
2. The Coverage Gap During Transition
The migration window is a genuine risk period. Workloads move, new clusters spin up, IAM changes to support the new architecture, and the team is focused on getting Kubernetes working rather than on securing it. If security tooling has to be reconfigured or re-purchased for the new platform, that gap widens precisely when the environment is most in flux.
3. Attack Paths Change Shape on Kubernetes
On EC2, an attack path runs through instances, security groups, and IAM roles. On Kubernetes, it also runs through pod configurations, RBAC bindings, service accounts, and container-to-service relationships. A team that had mapped attack paths on EC2 could lose that view entirely on EKS unless the same analysis extends to the new resource types.
4. Runtime Protection Must Move With the Workloads
The provider’s runtime protection on EC2 was agent-based, covering both container and host-level activity, and Kubernetes runtime security applies the same idea to pods. Kubernetes changes how workloads are scheduled and run. If moving to EKS meant abandoning that runtime coverage until a new solution was deployed and tuned, the migration would strip away the very protection the team had just put in place.
The Cloudanix Solution
One Asset Graph That Absorbs Kubernetes
Cloudanix builds a unified asset graph across the AWS environment, EC2 instances, IAM roles, security groups, data stores, and the relationships between them. When the provider migrates to Kubernetes, the graph does not get replaced; it expands. EKS clusters, pods, service accounts, RBAC bindings, and network policies are added as new node and edge types alongside the existing cloud resources. The team’s mental model, and the platform’s, stays continuous.
CSPM That Treats EC2 and EKS as First-Class
CSPM coverage established on the EC2 environment extends to Kubernetes posture (KSPM) as clusters come online: cluster configuration, pod security, RBAC analysis, service-account misconfigurations, and network-policy gaps. The same agentless, read-only connection that surfaced EC2 misconfigurations continues to surface EKS misconfigurations, so posture management does not restart at the migration.
Runtime Protection That Redeploys, Not Rebuilds
Because Cloudanix Workload Protection is agent-based, moving to Kubernetes is a redeployment of the same protection model, not a new decision. EKS runtime coverage is generally available, and onboarding a cluster is a single command that installs the agent across the workloads. The container and host-level runtime detection the provider relied on for Docker-on-EC2 carries directly into the EKS environment, with the same behavioural-baseline approach for the partner-built and AI-generated code being migrated.
Attack Paths That Extend to Pod and RBAC Context
Attack path analysis does not stop at the EC2 boundary. As Kubernetes resources enter the graph, the same traversal that identified exploitable chains across instances, security groups, and IAM roles now includes pod misconfigurations, RBAC bindings, and container-to-service relationships. The provider keeps the “fix the one or two changes that close the most paths” prioritisation across both platforms, rather than losing attack-path visibility exactly when the architecture becomes more complex.
Identity Continuity Through the Migration
The migration typically introduces new IAM roles and Kubernetes service accounts. CIEM keeps effective-access analysis, unused-permission detection, and right-sizing continuous across the change, so the identity clarity the team established on EC2 is not lost when new Kubernetes-specific identities appear.
Platform Impact
One graph EC2 and EKS on the same asset model | One command To onboard runtime protection to a cluster | No coverage gap Security continuous through the transition | Attack paths Extended to pods, RBAC, and service accounts
The Bigger Picture: Migrations Are When Security Quietly Regresses
The dangerous moment in a platform migration is not the cutover; it is the weeks around it, when the team is rebuilding operational muscle for a new runtime and security controls are half-configured. Teams that assemble a different tool for each platform pay this cost twice: once to set up Kubernetes security, and again in the exposure window while they do.
A unified platform changes the shape of the migration. Instead of a re-tooling project, Kubernetes security becomes an expansion of what already exists, more node types on the same graph, one more command to place the same agent, the same attack-path math over a larger surface. For a lean healthcare team migrating applications it did not write, continuity is not a luxury feature. It is what keeps patient-data workloads covered on the exact day they are most in motion.
The Outcome
The provider is positioned to migrate from Docker-on-EC2 to Kubernetes without resetting its security posture. Posture management, runtime protection, identity analysis, and attack-path prioritisation all extend to EKS from the same platform, the graph expands, the agent redeploys with one command, and the attack-path view grows to include pod and RBAC context. There is no second tooling decision and no planned coverage gap during the transition.
Key Results
✅ Unified Graph: EC2 and EKS resources on one asset model, no replacement at migration.
✅ KSPM Continuity: Posture coverage extends to cluster config, pod security, RBAC, and network policies.
✅ Runtime Redeploys: Agent-based container and host protection extends to EKS via one-command onboarding.
✅ Attack Paths Extended: Chains now include pods, RBAC bindings, and service accounts.
✅ Identity Continuity: CIEM keeps effective-access and right-sizing current through new K8s identities.
✅ No Coverage Gap: Security stays continuous through the highest-risk phase of the migration.
Migrating to Kubernetes Without Losing Your Security Posture?
Cloudanix keeps your cloud security continuous across the move from EC2 to EKS, one asset graph, one-command runtime onboarding, and attack-path analysis that extends to pods and RBAC. No re-tooling, no coverage gap at the migration.
Book a Free Assessment to see your environment through Cloudanix.
Related Resources
- What is CNAPP (Cloud-Native Application Protection Platform)?
- Cloud Workload Protection (CWPP)
- Attack Path: Walk the Chain From Internet to Crown Jewel
- Container Security and Real-Time Visibility for Modern Cloud
- Securing Healthcare Applications Built by Partners and AI
- Runtime Workload Protection for Docker-on-EC2 in Healthcare
