What Is Cloud Native Security? A Complete Beginner’s Guide

Cloud Native Security (CNS) operates as an architecture-focused security framework that differs completely from traditional security systems that depend on perimeter defenses. The traditional security framework bases its threat protection on external sources through defensive measures that include firewalls and VPNs.

The technology industry now uses “cloud native” as its primary development approach because it enables dynamic deployment of applications. The new security framework needs to use attribute and metadata-based workload identification instead of IP addresses for static identification because modern computing systems have become more complex.

Cloud Native Security functions as a complex system that requires multiple security objectives to protect cloud-native applications and technology from various security constraints.

The main objectives of CNS focus on delivering high availability, together with integrity protection, trust maintenance, and scalable system resilience. The security framework of CNS integrates protection mechanisms at all application layers, starting from microservices and containers up to serverless components, because it assumes that security breaches can occur at any point.

The new security approach requires organizations to implement security at all stages of application development, from development through distribution and deployment to runtime operations. Organizations achieve better security by implementing security measures at every stage of the application lifecycle, which consists of the Develop, Distribute, Deploy, and Runtime phases.

The Fundamental Principles of Cloud Native Security

Securing dynamic cloud environments, something that modern leaders experience frequently, either by taking part in the experience or observing it at their organization, calls for following fundamental principles that balance agility with security protection. These tenets underpin the philosophy of cloud native security.

Shift Left Security: Integrating Early and Often

Shift Left Security advocates that security is thought of and integrated much earlier in the Software Development Lifecycle (SDLC), ideally starting within the design/development phase. Integration of security is a critical element of DevSecOps, which furthermore embeds security into a development pipeline.

Security integrated early allows for preventative security instead of reactive security. Addressing security concerns earlier in the lifecycle prevents the need for rework later in the lifecycle, which slows down a DevOps pipeline and results in higher costs overall. Early integration enables security vulnerabilities to be identified sooner, resulting in a reduced likelihood of costly security events and slowdowns due to the accumulation of technical debt.

The Principle of Least Privilege

This is a security principle where users are given only the minimum access to get their job done. This principle must be applied to every layer of the cloud native stack.

In a cloud-native environment, least privilege focuses on applying permissions to streamline attack surface management (ASM) and reduce the blast radius in the event of a compromise. Those implementations may include:

• Rootless Containers: It is always best to designate a non-root user at build time as opposed to only relying on the runAsUser at runtime. By using a rootless container to run services, the pre-existing control plane component doesn’t have as much impact as it could if run as root, since an attacker gaining container access would not be able to escape and become root on the host.
• Immutable File Systems: When enabled, the readOnlyRootFileSystem feature prohibits the execution and tampering with containers at runtime. All necessary read/write functions may be limited on an as-needed basis with explicit directories leveraging tmpfs volume mounts.

Zero Trust Architecture: Never Trust, Always Verify

Zero Trust Architecture (ZTA) is a security architecture that is based upon the principle of (never trust, always verify. In the context of cloud-native architecture, ZTA addresses the risk of lateral movement within a network by not allowing for implied trust and enabling fine-grained segmentation.

ZTA requires any entity, device, or context to be re-verified every time an access request is made. In the world of containerized applications running as microservices, the security perimeter is every microservice. To decrease the blast radius in the event a microservice is compromised, ZTA limits a microservice’s communications to only other pre-approved and sanctioned microservice pairs. The zero-trust architecture has a strong root of trust that ties a tamper-resistant identity to the entity or process and attests to validate and prove that identity.

Ensuring Security Throughout the Cloud Native Application Lifecycle

Securing the Cloud Native Application Lifecycle requires embedding security across the various continuous phases: Develop, Distribute, Deploy, and Runtime.

1. Develop Phase: Security by Design

The application lifecycle kicks off in the development phase by creating artifacts such as Infrastructure as Code (IaC) templates and application manifests. Artifacts generated during this phase can represent a source for multiple attack vectors. Therefore, security hardening needs to begin at this point in order to significantly reduce the attack surface that will be deployed at runtime.

• Early Checks for Security: Security requirements should be taken as seriously as any other design requirement, frequently or in the process of a threat modeling exercise. Specific tools for security hardening would then identify misconfigurations and vulnerabilities before deployment.
• IaC Scanning: Insecure configurations in Infrastructure as Code templates (such as lackadaisical firewall settings or containers that allow privilege escalation) lead to security gaps in the built infrastructure part of the deployment. Tools should scan Infrastructure as Code templates either while in the developer’s integrated development environment (IDE) or as part of a pull request and source code repository.
• Code Review: It is encouraged that teams use the “four eyes” principle for code review prior to merging branches to avoid unintended security issues.

Organizations must invest in tools that enable the development teams to act quickly on rich and contextual security information. A proactive approach will help ensure that there are no high-risk configurations or known vulnerabilities.

For instance, platform teams should scan for insecure configurations in Infrastructure as Code templates early on in the Develop phase to facilitate concrete good outcomes in security posture as a result. [Wiz Link 1: Cloud Native Security Posture Management]

2. Distribute Phase: Security for the Supply Chain

The Distribute phase is heavily focused on Software Supply Chain Safety. Since it is necessary to use open-source software, periodic scanning and renewal of your artifacts (for instance, container images) to maintain safety is limited in an automated way.

• Image Scanning: Scanning container images remains one of the most common means of securing container-based applications. e Conversely, scanning needs to occur in your Continuous Integration (CI) pipeline prior to deployment and to continue to scan during runtime to ascertain what new vulnerabilities are found. Having this capability determines what vulnerabilities exist, the severity (using CVSS score), and whether there is a fix.
• Image Hardening: Images must also be hardened, including addressing threats such as locking down the execution environment to only allow a specific user to run it, and limiting access to resources.
• Artifact Integrity and Trust: It is critical to cryptographically sign all components to establish trust and integrity and provide non-repudiation for your artifact, in order to be able to protect image data from being tampered with between when it was built and runtime. This is ensured by validation of the signed data and trust established around the provenance of the artifact.
• If, for any reason, an artifact is established as untrustworthy (for example, by an exploit, etc.) at the origin, then we must also have a means of revocation of the signing keys and have established parameters around repudiation.
• Registry Staging: Organizations should use multiple registry stages–first, utilize an internal registry or registry mechanism to store vetted base images, which will then be used in a second stage as a private registry to run development artifacts. This will facilitate an organization maintaining a tighter grip on provenance and security of its development components.
• Dedicated access control and a clear authentication & permission model must be established for all registries. Use mutually authenticated TLS only when build tools access the registry.

3. Deploy Phase: The Final Check

The Deploy phase consists of a series of pre-flight checks, which are the last chance to verify, remediate, and enforce security policies before a workload is started.

• Pre-Flight Deployment Checks involve ensuring the existence, applicability, and current state of the following layers:
  • Signature and integrity of the image.
  • Runtime policies of the image (e.g., no critical vulnerabilities).
  • Runtime policies of the container (e.g., no excessive rights).
  • Workload/application/network security policies.
• Observability: Secure workload observability features (deployed accompanying the workload) are important at this phase to allow logging and available metrics to be monitored with a high level of trust to complement integrated security.

4. Runtime Phase: Monitoring and Enforcement

The Runtime phase is securing the live environment that consists of the compute, access, and storage layers.

• Orchestration Hardening (Kubernetes): Orchestration systems (e.g., Kubernetes) have many threats, from malicious access of the API, changing the key-value store (Etcd), and misuse of the API.
• Control Plane: Must be secured. Remember, in Kubernetes 1.20, they removed the insecure port from the API server. Etcd needs to only allow certificates issued to the API server to minimize the attack surface.
• API Auditing: Log Auditing is a reliable way to identify and correlate attacker/system compromise, abuse, or misconfiguration. It’s important to tune audit logging to include only logs covering events that fall into the organization’s agreed-upon threat model, such as logging different API endpoints.
• Network Policies: Network policies function to establish resource isolation and control network traffic between pods, which reduces the attack surface.
• Secrets Management: The built-in Kubernetes Secrets system serves as the native solution for secret management, but external secrets providers like csi-secrets-store offer alternative solutions when organizations need a single secret repository. Native secrets become secure when organizations use external Key Management Services (KMS) for encryption.

Also, as containers are software-based virtualization on shared hosts, to reduce the attack surface, a container-specific read-only operating system with all other services disabled must be used. Additionally, running rootless services and containers offers another layer of isolation.

Tried-and-Tested Strategies for Ongoing Security Assurance

Good security involves a mix of assurance mechanisms, ongoing auditing, and centralized risk management specifically designed for cloud native environments.

1. Threat Modeling and Risk Identification

Threat modeling is the primary way organizations adopting cloud native practices identify risks, controls, and mitigations. This begins by packaging a scoped representation of the organization’s architecture, including the building blocks, processes, and data stores, to identify security boundaries.

Noted by the NSA/CISA in their Kubernetes Hardening Guidance, three layers of compromise are specifically identified as they create a threat model:

1. Bugs and vulnerabilities in the supply chain,
2. Deliberate threat actor(s),
3. Insider threats (either administrators, users, or cloud service providers).

The following list presents four security threats that affect cloud resources.

• A cyber threat that starts with limited access to a system will eventually obtain elevated privileges through Elevation of Privilege (EoP).
• Information Disclosure occurs when unauthorized users gain access to sensitive data because of system misconfigurations, coding mistakes, and inadequate design choices.
• A workload that runs indefinitely will use up all resources on a node until it exhausts its CPUs and Memory, thus causing a Denial of Service (DoS).
• The production stage becomes vulnerable to Supply Chain Attacks because attackers use compromised materials and processes.

Organizations can develop security controls that protect their systems from daily threats through threat model implementation.

2. Visibility, Observability, and Auditing

Good security in these rapidly changing cloud native environments cannot realistically expect the level of accuracy and granularity that traditional security tools provide for assurance. Cloud-native security has a strong focus on real-time observability through distributed tracing and log aggregation.

Audit logging configuration should be verified against the organization’s threat model. Audit logs should be consumed for review purposes as close to real-time as possible, and if audit logs can be determined to be compromised while reviewing audit logs, the log data needs to be protected from modification. In general, centralization of logs in an alertable mode to an off-cluster potential by webhook to get alerts after a critical event occurs, and to review.

Visibility is key to managing a distributed system, because it allows you to have full visibility. A platform that provides full visibility of the entire ecosystem and demonstrates visibility measures all logs, audit logs, alerts, compliance, vulnerabilities, etc., but from a centralized risk management platform, as a security team, it allows for better understanding and risk posture across all runtime environments, which is significant at runtime. [Wiz Link 2: Cloud Native Visibility and Risk Management Platform].

3. Assuring Software Supply Chain Integrity

The integrity of the supply chain ultimately rests on verification of the integrity and provenance of artifacts. Two critical documents are critical to this:

Software Bill of Materials (SBOMs)

An SBOM is a complete list of all components, libraries, and dependencies used in an application. An SBOM helps consumers understand their transitive dependencies and supports vulnerability management, license management, and incident response processes. This should be provided in a standardized format, such as SPDX or CycloneDX, and ideally at build time.

Vulnerability Exploitability eXchange (VEX) Documents

VEX documents are a preemptive model that communicates the exploitability and known vulnerabilities of specific components, particularly in the supply chain. This consideration is important because a component can be listed as vulnerable in an SBOM; however, a vulnerability may not actually be exploitable in the context of the application (e.g., an improperly invoked code path, conditional on a compile option that is off). This helps organizations focus on real risks and develop priorities and timing for publicly available vulnerabilities.

Make Security a Collaborative Culture

Cloud-native security systems need to function as a team while integrating with development processes. The path to success depends on developers, operators, and security experts who will unite to develop and implement secure cloud-native patterns. The fast-paced nature of these environments demands automation for secure outcomes, but security controls need to follow the specific threat model of the environment.

Cloud-native security adoption moves away from traditional perimeter-based defenses with their static nature to implement model-based security that operates dynamically. Security functions as an integrated system that enables developers to build security features into their applications throughout the development process. The implementation of security requirements at modern application speeds demands complete supply chain integrity verification and eBPF-based kernel-level enforcement and policy embedding throughout the system.