Securing the 4 Cs of Cloud-Native Systems: Cloud, Cluster, Container, and Code

By Magno Logan (Threat Researcher)

Cloud-native computing is a software development approach for building and running scalable applications in the cloud — whether on public, private, on-premises, or hybrid cloud environments. Cloud-native computing leverages both open-source and non-open-source software to deploy applications such as microservices that are packaged into individual containers. A container, such as a Docker container, is used for packaging all the necessary software and applications into isolated executable processes. Since organizations usually run multiple containers across multiple hosts, they use orchestration systems, such as Kubernetes, that are then managed and deployed via CI/CD tools leveraging DevOps methodologies. Ultimately, cloud-native technologies enable businesses to make the most of their cloud resources with less overhead, faster response times, and easier management. 

Like any technology that uses various interconnected tools and platforms, security plays a vital role in cloud-native computing. If there’s one thing that security experts unequivocally agree on, it’s the fact that there are no modern complex software systems that are entirely “unhackable” — there’s no such system, device, or environment that is 100% impenetrable. This has led to the application of defense-in-depth, a concept adopted from the military, in the realm of cybersecurity.

Defense-in-depth makes use of multiple layers of control and establishes security barriers across different areas within an organization to provide multilayered protection in case one of its controls fails or becomes exploited. Cloud-native security adopts this approach and divides the security strategies utilized in cloud-native systems into four different layers, as seen in the diagram below called “The 4Cs of Cloud-native Security.”

Figure 1. The 4 Cs of cloud-native security

It is very important to apply security controls to each layer; otherwise, it could leave applications vulnerable to attacks because each layer provides its own attack surface and may not be protected by the other layers.  For instance: an insecure web application that gets attacked with an SQL injection will not receive protection from the outer layers as seen in figure 1 without the use of some specialized third-party software. Cybersecurity defenders need to cover every possible scenario and protect systems in every possible way. And as tough as it sounds, sometimes attackers only need to find one issue to compromise the entire system. This article details the most common security issues found in each cloud-native layer and provides detection and prevention tips.

Cloud Security

In this framework, the cloud layer refers to the infrastructure that runs servers. There are many different services involved in setting up a server on your preferred Cloud Service Provider (CSP). And although most of the responsibility for securing such services (e.g., operating system, platform management, and network configuration) lies with the CSPs, the customer is still responsible for checking and configuring these services, as well as overseeing and securing their data. This shared responsibility model is essential to understand and leverage when deciding to move organizational resources and services to the cloud.

These are the most common issues found in today’s cloud systems:

• Misconfiguration Issues – As the number of components for various cloud architectures increase, we also expect to see a rise in the number of misconfigurations. Though a product of possible user neglect or naivete, misconfigurations are often taken advantage of by cybercriminals, costing businesses large sums of money and even their reputations. Configuration issues are quite common. For example, misconfiguration issues allowed attackers to add cryptocurrency miners via Tesla’s Kubernetes administration console. Many services and applications are created with default settings that leave them exposed to the internet, and many bots and threat actors are waiting to exploit them. Recently, we’ve observed how threat actors abuse exposed Redis instances to perform remote code execution (RCE) or turn them into cryptocurrency-mining bots.

• Automation –Automation is good for improving the speed of creating new systems and deploying new applications, however, it can also propagate errors and security issues much faster if they are not properly checked and monitored. Aside from the threats themselves, the speed in which threats can be deployed in a vulnerable web-connected system or device is also alarming. In one study, researchers discovered that it only took 52 seconds for cybercriminals to scan and attack their unsecured devices via honeypots that the researchers set up. Hence, organizations must be able to secure the different facets of their architecture properly and efficiently.

Organizations can avoid running into these problems by following their cloud provider’s recommendations and performing regular audits to make sure that everything is configured properly before they’re deployed to production and exposed to the internet.

The adoption of infrastructure as code (IaC) practices is an effective measure that ensures systems are created properly and their configurations remain as intended. IaC uses code to automate the proper provisioning of IT architectures, which allows for the elimination of manual provisioning by DevOps engineers, therefore minimizing oversight and human errors as long as best practices are followed. Tools like Terraform, Ansible, and CloudFormation are great ways to define the baseline settings of your infrastructure, including its security settings. It also helps ensure that such settings remain unchanged unless someone approves and deploys the necessary code to change to them.

Using IaC practices is the new normal when it comes to creating and building cloud environments, and it enables organizations to make the most of the different levels of automation as well as its deployment speeds. There is really no need to spin up and configure servers manually nowadays — automation is key in securing cloud architectures.

Also, make sure you follow your CSP’s security recommendations. Here are some of the most popular CSPs’ security best practices:

• Amazon Web Services - https://aws.amazon.com/security/
• Google Cloud Platform - https://cloud.google.com/security/
• Microsoft Azure - https://docs.microsoft.com/en-us/azure/security/azure-security

Solutions that provide visibility into cloud architectures and automate security and compliance checks, such as Trend Micro™ Cloud One – Conformity, help simplify and optimize security in this layer. 

Cluster Security

When talking about cluster security, we’ll focus mostly on Kubernetes since it is the most used container orchestration tool today, however, the security principles discussed can also be applied to other solutions as well.

There are three main cluster elements that organizations need to be concerned about:

• Cluster components. This is related to protecting the components that make up your cluster, or the master node, in the case of Kubernetes. Things like controlling API server access and restricting direct access to etcd, which is Kubernetes’s primary datastore, should be top of mind when it comes to cluster security. Kubernetes has a comprehensive document that discusses how to protect clusters from accidental or malicious access. In a recent article, we discussed how we observed 3,000 hosts where etcd was seen to have been publicly exposed. To avoid this, we recommend that cloud administrators deny access by default and allow traffic only explicitly. Unless you have a large team and/or any strict compliance requirements it is recommended to make use of cluster managed services such as Azure Kubernetes Service (AKS), Elastic Kubernetes Service (EKS) or Google Kubernetes Engine (GKE).

• Cluster services. This applies to the proper configuration and access control for the services running in the cluster. To secure these services, Kubernetes recommends employing certain protective measures such as resource management and running services with the least privilege. Make sure to set proper authentication and authorization to your clusters, encrypt traffic using Transport Layer Security (TLS), and protect sensitive information using secrets. We also recommend that you take a look at the (Center for Internet (CIS) Kubernetes Benchmark for more technical details on securing your cluster services.  

• Cluster networking. This is related to the proper allocation of ports to facilitate communication between containers, pods, and services. It’s important to ensure that the Kubernetes networking model is implemented securely using a Container Network Interface (CNI) that will allow users to restrict pod traffic.

We provide more detailed recommendations for securing container orchestration in our guide on Kubernetes threat modeling.

Container Security

 Container Runtime Engines (CREs) are needed for running the containers in the cluster. Although Docker is one of the most popular CREs, Kubernetes also supports others such as containerd or CRI-O. There are three main things that organizations need to be concerned about with this layer:

• How secure are your images? This comes down to making sure your containers are up-to-date and free of any major vulnerability that could be exploited by a threat actor. Organizations should secure not just the base image, but also ensure that the applications running in their containers have been scanned and verified. Although there are some open-source tools available for this purpose, not all of them can detect vulnerabilities beyond OS packages. For this, organizations can use a solution that covers the application vulnerabilities as well, such as Deep Security™ Smart Check. 

• Can they be trusted? Are the containers running in your system built from the images in your registries? How can you ensure that? By using image signing tools such as TUF or Notary, you can sign your images and maintain a system of trust for the content of your containers.

• Are they running with proper privileges? The principle of least privilege applies here. You should only run containers with users that have the minimal OS privileges necessary to carry out their tasks. We’ve previously expounded on why it’s a bad idea to run privileged containers in Docker, or containers that have all the root capabilities of a host machine.

We created a comprehensive guide on how containers can be better protected via an examination of the potential threats at each stage of the development pipeline.                                                                                                                 

Code Security

This can also be called application security, and it is the layer that organizations have the most control over. The code of your applications is the heart of your systems, along with their respective databases, and are usually exposed to the internet — hence, attackers will focus on this if all other components are secured properly. So how can organizations ensure that their apps are coded properly and securely when they have tens, hundreds, or maybe thousands of developers writing and deploying code every day to their production environment?

First, organizations must ensure that all communications are being made using TLS Encryption, even between internal services like load balancers, application servers, and databases. When using an orchestration tool like Kubernetes, services like Istio or Linkerd can be leveraged.

Organizations can greatly reduce the attack surface of their systems just by limiting and monitoring exposed services, ports, and API endpoints. Here, it is important to also think about the container base images and the systems on which your clusters are running.

There are various code security verifications that you can add to your pipeline to make sure that your code is secured. Here are a few of those: 

• Static application security analysis. Also called “security code review” or “code auditing,” this is still one of the best and quickest ways to detect security issues in your code. Regardless of the language that you are using, you should have at least one static analysis tool embedded into your pipeline that checks for unsafe coding practices every time your developers commit new code. The Open Web Application Security Project (OWASP) Foundation has a list of open-source and commercial tools designed to analyze source code and/or compiled code to detect security flaws.

• Dynamic application security analysis. Although dynamic analysis can only be done when you have a running application to test against, it is also a good idea to perform automated scans and checks to test for common application attacks such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF). These tools will also test the resilience of your application, container, and cluster when faced with a series of unexpected load and malformed requests. OWASP has a dynamic analysis tool that can also be automated and embedded into your pipeline called OWASP Zed Attack Proxy (ZAP).

• Software composition analysis. Between 70% and 90% of all cloud-native applications are made of libraries or third-party dependencies. These are chunks of code — code probably written by someone outside your organization — that are embedded and running inside your production systems. These codes are generally not checked during the static analysis phase. Tools like the OWASP dependency-check can be used to check for outdated or vulnerable libraries in your code. Snyk also offers free third-party verification for open source projects.

The four layers of cloud-native systems are vital for keeping applications secure — and leaving just one of them exposed to attackers will give them the leverage that they need to compromise the entire system. Ensuring that your cloud-native system is resilient is essential in keeping your organization productive, dynamic, and ultimately, afloat.

Trend Micro’s cloud security solutions

Cloud-specific security solutions such as Trend Micro™ Hybrid Cloud Security can help protect cloud-native systems and its various layers. It is powered by Trend Micro Cloud One™ , a security services platform for cloud builders that provides automated protection for the CI/CD pipeline and applications. It also helps identify and resolve security issues sooner and improve delivery time for DevOps teams. It includes:

• Workload Security: runtime protection for workloads
• Container Security: automated container image and registry scanning
• File Storage Security: security for cloud file and object storage services
• Network Security: cloud network layer IPS security
• Application Security: security for serverless functions, APIs, and applications
• Conformity: real-time security for cloud infrastructure — secure, optimize, comply