Cloud-native security: Securing Kubernetes and containerized environments

Cloud native security is about building and running apps in the cloud with security baked in from day one. This means that securing containers and Kubernetes—the bread and butter of cloud native apps—is a top priority.  

Kubernetes does all the heavy lifting: scheduling, scaling, networking, and self-healing containerized applications. However, Kubernetes is not considered to be secure by default, making hardening cloud-native applications the developer's responsibility.  

The CNCF Q3 2025 report estimates that there are currently 15.6 million cloud native developers, an all-time high. Developers can wear many hats, switching between platform operations, CI/CD automation, observability, and incident response. With their responsibilities on the rise, security often becomes a bolt-on step at the end of the pipeline, instead of a requirement baked into every stage.  

This is where cloud native security steps in: It’s all about treating security as part of the application and platform design itself. 

Evolution of Cloud Native Security 

Historically, managing infrastructure has been guesswork.  

The AWS pay-as-you-go model made developers think of infrastructure as a commodity instead of a fixed capital expense. Once that model took off, Google, Microsoft, and others started offering almost everything as a service in the cloud.  

Two decades later, almost every enterprise on the planet is cloud-first, and it’s clear the cloud is here to stay. 

Unfortunately, the speed of cloud adoption brought a wave of security challenges that the industry wasn’t ready for. The security standards built for pre-cloud monolithic applications didn’t fit microservice-first, cloud-native architectures. Cloud agility also added complexity, which in turn increased the risk of human error.  

Threat actors are now increasingly focused on cloud and containerized environments, with known cybercrime groups popping up, such as TeamTNT, Kinsing, and the 8220 Gang.  

Threat Adversary Models 

In response to this shifting threat landscape, adversary models like MITRE ATT&CK’s container matrix and DevSecOps hardening principles were developed to help organizations:  

• Track evolving attack patterns 
• Prioritize their security roadmap 
• Define detection logic 
• Rehearse realistic attacker movements across clusters 

MITRE’s Center for Threat-Informed Defense (CTID) published this framework in 2021 to provide a unified view of adversary behaviors on both the orchestration level (e.g., Kubernetes) and the container level (e.g., Docker).  

The ATT&CK framework is continuously updated with newly observed attacker profiles and emerging attack techniques. Notably, in cloud native container environments, resource hijacking campaigns such as cryptojacking and cryptomining are often enabled by backdoors and misconfigurations.  

The community-maintained repository of AWS customer security incidents consists of 127 incidents from 2014 to 2025, with incidents related to cryptomining and cryptojacking taking the highest share (17.32%).  

Knowing these kinds of attack paths and having a unified view, such as via the MITRE ATT&CK framework, has helped security professionals move from being gatekeepers to enablers, taking full advantage of cloud native. 

Threat Model for Cloud Native Workloads 

Threat modeling is the first step towards securing environments. It involves identifying how a system can be compromised, mapping potential attack paths, and deciding where to place controls to mitigate the risks. 

Microsoft breaks the threat modeling exercise into four main steps for modern ecosystems:  

1. Design stage: Capture all the requirements for the system and create a data-flow diagram (DFD).  

2. Break stage: Use DFD to identify potential threats against the system. Microsoft recommends the STRIDE model, grouping threats into six categories to provide a broad (albeit not exhaustive) list of potential threats. This is also known as a depth-first/bottom-up approach: Prioritize and drill down into components flagged as highest risk. 

3. Fix stage (Figure 5): Prioritize threats based on risk levels (high, medium, and low), and identify your acceptable range of risk. The upper boundary represents a level of risk whose cost impact would be too great for the organization to bear, while the lower boundary shows where the additional cost of countermeasures outweighs the benefit of further reducing residual risk. 

4. Verify stage: Run both manual and automated verification before deployment.

Similarly, the Threat Modeling Manifesto breaks down threat modeling into four actionable questions. However, this traditional threat modeling is not built for most of the modern cloud-native or hybrid systems.  

That’s why the cloud native computing fundation (CNCF) published an open source threat manual for threat modeling in cloud native environments, with the following preferences:  

• Implement “Design stage” approaches, e.g., using DFDs to provide an end-to-end view of data management within a system to identify and mitigate security risks.  
• Be wary of inefficiencies in the STRIDE model at the “Break stage” due to the inherent architecture of cloud native systems. Use the privacy-by-design framework LINDDUN. 
• At the “Fix stage,” implement models such as factor analysis of information risk (FAIR) and rapid risk assessment (RRA) for categorizing risk.  
• At the “Verify stage,” conduct a TAG-Security and Compliance Security Assessment (TSSA) to eliminate security risks.  

Best Practices for Cloud Native Security: A Layered Approach 

Threat modeling tells where you’re most exposed. It answers the question: “What could go wrong?”  

But to translate those risks into concrete controls, you need best practices. There are multiple ways to approach cloud native security best practices, but we’ll present a layered approach in accordance with this 2022 CNCF white paper. 

Application Lifecycle Layer Best Practices 

The cloud native application lifecycle has four stages: develop, distribute, deploy, and runtime. Security needs to be baked into each of these stages: 

• Treat security as a design requirement in the develop phase: Run static analysis, dependency checks, and manifest scanning in IDEs and on every pull request. The resulting short feedback loops allow teams to fix misconfigurations and vulnerable libraries while the required change is still small and easy to understand.  
• Build security tests around high-risk application paths: Whenever a misconfiguration or vulnerability is found in production or staging, add an automated test that reproduces it.  
• Harden application images and manifests as part of development: Treat Dockerfiles and Kubernetes manifests as part of the application, and design them with least privilege in mind. For example, a pod manifest could include the following controls: 
  • runAsNonRoot: true makes sure the container runs as a non-root user. 
  • allowPrivilegeEscalation: false prevents the container from gaining more privileges than its parent process. 
  • capabilities: drop: ["ALL"] removes all Linux kernel capabilities (e.g., CAP_NET_ADMIN, CAP_SYS_ADMIN), providing only a baseline of permissions. 
  • readOnlyRootFilesystem: true makes sure the container's root filesystem is immutable. 
• Secure the distribution pipeline for application artifacts: Only promote artifacts through controlled internal registries with strong access control and mutual transport layer security (TLS). As part of the same flow:  
  • Scan images on build and then regularly for known vulnerabilities and malware. 
  • Sign images and critical configuration files. 
  • Verify those signatures before deployment. 
• Enforce admission and deployment policies at the cluster boundary: Use admission controllers or equivalent policy engines to enforce minimum security standards. This includes:  
  • Validating image signatures 
  • Checking vulnerability posture 
  • Evaluating manifests against least-privilege policies 
• Design applications for observability and incident response from day one: Build logging, metrics, and tracing into the application from the get-go to shed light on security-relevant behavior.  

Runtime Environment Layer Best Practices 

The security of the runtime environment depends on how effectively security practices are applied across compute, access, and storage, with controls baked into each layer, as shown in the table below. 

Security practices across compute, access, and storage:

 Although it's realistic for developers to know the basics about controls and best practices, it’s not practical to manually enforce them.  

In modern, heavily automated environments, there are tools for almost everything, which the CNCF explores in detail in its Cloud Native Security Map.  

Note: Implementations must align with reference guidance such as NIST SP 800-204 so that you’re not just hardening clusters ad hoc, but moving toward a consistent, standards-informed runtime security posture.  

Where to Go from Here 

Cloud native security is less about learning another list of controls and more about wiring those controls into how you design, ship, and run software. Threat models, ATT&CK, and layered best practices only pay off if they end up as policies, pipelines, and runtime guardrails that update as fast as your clusters do.  

Looking ahead, the interesting work is not “adding one more scanner.” Instead, companies should be moving towards policy-as-code, real-time posture checks across Kubernetes and storage, and closer alignment with reference models. This way, future multi-cloud and hybrid setups won’t turn into a set of one-off exceptions. 

RapidScale makes cloud-native security “real” by doing the build plus the ongoing enforcement:  

• Design and deploy the Kubernetes foundation, then provision cluster and node groups and harden node images. 

• Wire in the controls like RBAC for least-privilege access, ingress controls, and integrations with SSO/directory services. 

• Continuously enforce controls and keep configurations consistent across AWS, Azure, and other environments via RapidScale’s Cloud Reliability Platform for real-time scanning and automated remediation workflows. 

If you’re looking to move beyond “We know the best practices” to “Our clusters actually enforce them by default,” send our team a message today to bridge that gap.