By Sarabjeet Chugh, Head of Product-Led Growth, Emerging Technologies and Incubations group, Cisco

Cloud native application development started gaining serious traction in around 2013 with the launch of the Docker project. With the growth and popularity of Kubernetes, cloud native development has now become one of the fastest-growing trends in tech. Kubernetes relieves developers from worrying about infrastructure and easily deploys their applications using a containerized application image, along with a set of declarative instructions.

Both Gartner and IDC have forecasted that 90% - 95% of apps will be cloud native by 2025, and with good reason: cloud native apps are flexible, built to scale, and resilient. They facilitate faster delivery, since microservices can be added and upgraded without the necessity to re-release an entire monolithic application. They're also less expensive to deploy, since there's no hardware to provision.

As these technologies have grown in popularity, the approaches to cloud native security have developed in tandem. In this article, we'll look at the evolution of cloud native security techniques and examine the developing trends.

Why cloud native application security requires a different approach

Although traditional cloud security tools (cloud firewalls, defined security groups, VM agents, logs, and metrics) are important, they're not sufficient to protect cloud native applications. Decentralized architecture, with its proliferation of containers, serverless functions, and APIs, has provided attack surfaces that extend beyond infrastructure.  

Large cloud native applications, such as Netflix and Amazon, are composed of hundreds of microservices, each with its own API. Each API has multiple access-control rules, which are in constant flux. What's more, these services often integrate open source code. Because of all these moving parts, it can be difficult to trace a code-injection vulnerability back to its origin. The Kubernetes environment itself also presents opportunities for exploitation.

For all these reasons, cloud native workloads require a new breed of security tools, capabilities, and processes.

Kubernetes and container scanning

According to Gartner, containers and Kubernetes have emerged as prominent platform technologies for building cloud native apps and modernizing legacy workloads. Studies by the analyst firm found that more than 90% of global organizations will be running containerized applications in production by 2027-a significant increase from fewer than 40% in 2021.

Other research has echoed Gartner's predictions. In a study conducted by the analyst firm Dimensional Research in July of 2022, 60% percent of respondents said Kubernetes was their preferred or only way to deploy new production applications, with 43% of all workloads already in Kubernetes today. Ninety percent expected to add new applications and 79% expected to migrate existing applications to Kubernetes by 2023.

The most common areas of weakness with Kubernetes clusters are security misconfigurations and inadequate access controls. For this reason, Kubernetes scanners were among the first security tools specific to cloud native environments. Fortunately, there are a number of free open source tools for scanning Kubernetes container images. These solutions can identify vulnerabilities in the registry, before deployment, and in production, and provide remediation guidance.   

Running containers and Kubernetes in production presents its own set of onerous issues. Kubernetes does not enforce policies (thereby creating an enticing attack surface), raising the urgency to establish and deploy robust monitoring for vulnerabilities.

Infrastructure as Code (IaC)

IaC also has a unique set of challenges and best practices. Templates are one of the most critical areas to secure, since they come out of the box with unsecured default configurations that can threaten the entire environment. Master-node architecture provides a single point (or master) that contains deployment-related specifications. Misconfigurations in this area can be disastrous. Depending on how you store secrets with IaC, they may be easily exposed. Access management can also become an issue with IaC, because templates often don't require root privileges on the targeted machine. The principle of least privilege applies here. Other security hazards with IaC include configuration drift and risks related to data transmissions.

Combatting these vulnerabilities requires:

• Scanning for misconfigurations
• Using vaults for secrets
• Node-management software
• Monitoring for drift
• Encryption
• Audit logs that assess risks, identify potential threats, and analyze the root causes of incidents.

This OWASP IaC "cheat sheet" goes into greater depth.

Serverless functions

The Cloud Native Computing Foundation (CNCF) defines serverless computing as "the concept of building and running applications that do not require server management." It describes a finer-grained deployment model, where applications-bundled as one or more functions-are uploaded to a platform, and then executed, scaled, and billed in response to the exact demand needed at the moment.

There are two main types of serverless functions: Functions-as-a-Service, which are event-driven (triggered by events or HTTPS requests), and Backend-as-a-Service, which are third-party, API-based solutions that confer flexible scalability and economy (you only pay for resources that you use).

Despite its benefits, serverless computing comes with a few downsides, with security topping the list. While it's true that serverless computing shifts some of the security burden onto the cloud providers (such as patching, configuring infrastructure, and setting up account management), it also means that you have less visibility, making it more difficult to identify vulnerabilities or detect attacks. Their ephemeral nature further complicates the challenge. Traditional security approaches are inadequate here, because serverless functions often violate legacy security controls and pave the way for vulnerabilities.

Here are a few of the types of threats posed by serverless functions:

• Overprivileged functions  
• Broken authentication
• Inadequate monitoring and logging
• Insecure third-party dependencies
• Event-level injection (this might include untrusted inputs in application calls or code modifications-not just API calls)
• Insecure code/security misconfiguration that leads to application-level attacks
• Difficulty in tracking the source of attacks due to the ephemeral nature of these functions
  

Cisco's Emerging Technology and Incubation (ET&I) team plans to open source software for code signing and verification of serverless functions. Look out for an announcement at KubeCon event (see us at booth D3) for a demo of this functionality.

Software supply chain security

Supply chain security has become a growing focus for the industry, as well-thanks in part to an enhanced focus by the U.S. government, which held two open source security summits at the White House in 2022 after President Biden's 2021 mandate to improve the software bills of materials (SBOMs).

While SBOMs continue to be a major topic of discussion, new methodologies for securing the supply chain are beginning to surface. Supply chain levels for software artifacts (SLSA) is one of them. According to its authors at slsa.dev (a coalition of industry partners, plus the CNCF and Linux Foundation), SLSA is a "checklist of standards and controls to prevent tampering, improve integrity, and secure packages and infrastructure in your projects, businesses, or enterprises." These standards are designed to help the industry progress from "safe enough" to truly resilient at every link in the supply chain.

SLSA specifies four different levels of assurance:

1. Visibility and the ability to generate provenance
2. Protection against software tampering and adds guarantees for minimal build integrity
3. Hardening the infrastructure against attacks, integrating more trust into complex systems
4. The highest assurances of build integrity and established measures for dependency management in place
   

Get ready to hear much more about SLSA in the coming months.

The future of cloud native security

As architectures have evolved in the cloud native space, we can expect to see a continued and escalating focus on security. This focus will go beyond technology. The evolution of modern apps and decentralized applications are morphing the industry's entire approach to security. The trend is to "shift left," integrating security into every stage of the software development lifecycle. This journey has only just begun.

ET&I plans to announce new open source innovations under the OpenClarity project suite. At KubeCon + CloudNativeCon 2022, it will also showcase Istio Kafka and Logging Operators, API Insights, Project Zot, MSM, NSM, and GitBOM, among other open source initiatives. Stop by our booth (D3) at KubeCon + CloudNativeCon 2022 North America in Detroit!

##

To hear more about cloud native topics, join the Cloud Native Computing Foundation and the cloud native community at KubeCon + CloudNativeCon North America 2022 in Detroit (and virtual) from October 24-28.

ABOUT THE AUTHOR

Sarabjeet Chugh, Head of Product-Led Growth, Emerging Technologies and Incubations group, Cisco

 

Sarabjeet is the Head of Product-Led Growth at Cisco for Panoptica and Calisti products, which are based on open source technologies such as Istio and OpenClarity. Sarabjeet has 23 years of experience building and shipping products with open source technologies from CNCF and Linux Foundation, working at organizations like Pivotal Software, VMware, Oracle, and Cisco.