EXPEL BLOG

Comparison of cloud resources (part I): Securing every layer of your cloud—from the control plane to apps

alt=""

Cloud security · 5 MIN READ · ETHAN CHEN · MAR 26, 2025 · TAGS: AWS / Get technical / Kubernetes

TL;DR

  • This is part one of four in our Comparison of cloud resources blog series
  • For more, see parts two, three, and four once published
  • Part one covers layers of cloud infrastructure: the control plane, and the orchestration platform, and application layers

 

The complex, ever-changing nature of cloud infrastructure offers endless opportunities for attackers and poses endless challenges for defenders. Threats can exploit security gaps in any layer—from the control plane and orchestration layer to the cloud workloads and applications running in the environment. They can come in many forms, including misconfigured services, API vulnerabilities, malware infections, and malicious insider behavior. And signs of compromise can be just as varied. To protect your data and systems, your cloud security strategy has to ensure effective detection and response for the full spectrum of potential incidents. 

This blog series will explore cloud security in depth. We’ll discuss the layers to protect and define the tools available for each. In part four, we’ll offer a road map to reduce cloud security risks. We’ll also explore how Expel works to eliminate security gaps at every layer to help you achieve comprehensive protection for your cloud environments.

What are the layers of cloud infrastructure?

Cloud environments encompass an ever-changing mix of resources extending all the way from the provider’s data center to your own end-user devices. That complexity makes the cloud especially hard to secure. First, we must understand what happens at each layer of cloud infrastructure and the types of threats that can arise there. 

It’s helpful to think of your cloud infrastructure as a restaurant kitchen. Each layer plays a different role in preparing the meals—or business applications—you provide to ‌customers, your end users. 

A diagram of the layers of cloud infrastructure.

Cloud infrastructure layer (aka the control plane)

This is where services like AWS, Azure, Google Cloud, and Oracle Cloud Infrastructure (OCI) handle tasks such as resource provisioning, configuration management, and permissions setting for users. 

You can think of the control plane as the executive chef who oversees the entire kitchen and its operations. When planning for each week’s business, the control plane ensures the kitchen has all the needed cooking tools, ingredients, and staff (or compute, storage, and networking). With the kitchen layout set (or, the environment configured) for optimal quality, efficiency, and safety, the control plane oversees resource allocation to keep things running efficiently. In high-demand periods—like the dinner rush (or, a spike in end-user activity)—the control plane makes high-level decisions about what to prioritize and how to adjust. 

Common threats at this level include:

  • Compromised API keys: Attackers use compromised API keys to manipulate cloud resources by creating or deleting virtual machines (VMs), for example.
  • Misconfigured access controls: Overly permissive or poorly configured identity and access management (IAM) policies give attackers access to critical resources.
  • Unauthorized configuration changes: Adversaries modify control plane settings, such as permissions or network configurations, to enable lateral movement or persistent access. 

To stop these threats, organizations monitor logs, traffic, and configuration changes for unusual activity. Fortunately, many of these threats can trigger real-time alerts. You can learn more about specific types of cloud alerts in our two-part blog:

Orchestration layer

The orchestration layer is where SecOps teams manage their containerized workloads. (Note that these workloads actually run in the platform layer, which we’ll discuss next.) Orchestration platforms like Kubernetes—and related services such as Amazon Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS), and Google Kubernetes Engine (GKE)—operate at this layer to deploy, scale, and move cloud-native applications. 

The orchestration layer is like a sous chef who coordinates food prep for each meal service. It assigns tasks to chefs, makes sure ingredients are prepped at the right time, and manages the order flow from the dining room to the kitchen. If there’s a dinner special, the sous can reassign line cook tasks—or scale and move cloud-native applications across the environment to support changing requirements. 

The role of Kubernetes in orchestrating communications and moving resources across the network makes it an attractive target for cybercriminals as part of a broader attack. Potential security threats include:

  • Container misconfigurations: Attackers can take advantage of weak Kubernetes configurations—such as overly permissive network policies—to gain unauthorized access or take over the entire cluster.
  • Vulnerable container images: The deployment of container images with unpatched vulnerabilities allows attackers to bypass security controls, gain elevated permissions, or access the host system.
  • Exposed secrets: Poorly managed security for Kubernetes secrets allows attackers to access sensitive data like passwords, tokens, API keys, and certificates. 

As with the cloud infrastructure layer, DevOps teams must carefully analyze the logs for these platforms, monitor their traffic, and track configuration changes related to containers and VMs. Learn more about the nuances and challenges of Kubernetes security in our two-part blog series:

Platform layer 

The platform layer is where cloud workloads actually run, and it sits between the cloud infrastructure layer and the application layer. The platform layer hosts the virtual machines, containers, and serverless functions that execute the business logic powering end-user services. The platform layer is often provided as a platform-as-a-service (PaaS), helping developers focus on building applications without worrying about the underlying resources or setup. 

In our kitchen analogy, the platform layer corresponds to the line cooks preparing dishes. Each cook has all the equipment they need to perform assigned tasks, such as knives, cookware, and appliances (or, frameworks and runtime environments). In the simplest terms, the platform layer gets you from a cold kitchen full of raw ingredients to a piping-hot meal ready to eat.

For attackers, the platform layer can provide access to both compute resources and adjacent workloads. This offers opportunities for a broad range of attack types, including:

  • Malware installation: Threat actors install malware on compute instances to establish command-and-control communication, execute malware, or exfiltrate data.
  • VM escape attacks: Attackers exploit hypervisor vulnerabilities to break out of a VM and access other tenants’ workloads.
  • Credential theft: Stolen secure shell (SSH) keys or passwords allow unauthorized access to compute resources. 

The cloud alerts that help teams monitor their control plane for signs of threats can serve a similar role at the platform layer. Again, you can refer to our two-part blog series on cloud alerts to learn more:

Application layer

The cloud-based software that end users rely on—such as web browsers, SaaS apps, and custom web apps—all reside at the application layer. 

In a restaurant, these applications are the meals that emerge from the kitchen and land on patrons’ tables. These customers don’t need to know what happens in the kitchen—how its operations are managed, where the raw ingredients are stored, or what the line cooks do. They just consume the final product.

The application layer can be as useful for bad actors as it is for legitimate users. In addition to misconfigured access controls, which pose as much danger here as in the control plane, additional threats include:

  • Application-layer distributed denial-of-service (DDoS) attacks: Botnets launch a flood of bogus requests to overwhelm application resources and render services unavailable. 
  • Other application-layer attacks: Tactics like malformed packets, buffer overflows, and unauthorized function calls can all allow attackers to manipulate or damage applications. 
  • API exploits: Insecure APIs allow attackers to gain unauthorized access to application data or services. 
  • SQL injection: Attackers inject malicious SQL queries into applications to retrieve or manipulate sensitive data. 
  • Cross-site scripting (XSS): Malicious scripts injected into web pages execute in the browsers of users who view them.
  • Credential stuffing: Attackers use automated tools like botnets to try stolen user names and passwords across large numbers of websites and services. 

Detecting and preventing threats like these requires a full arsenal of tools—from firewalls and web application firewalls (WAFs) to runtime application self-protection (RASP) and application detection and response (ADR). We’ll explore these and many other tools for each layer of cloud infrastructure in part two of this blog series. 

Blog home