- Nouvelles de sécurité
- Virtualization & Cloud
- 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.
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:
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:
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.
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:
We provide more detailed recommendations for securing container orchestration in our guide on Kubernetes threat modeling.
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:
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.
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:
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.
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:
Like it? Add this infographic to your site:
1. Click on the box below. 2. Press Ctrl+A to select all. 3. Press Ctrl+C to copy. 4. Paste the code into your page (Ctrl+V).
Image will appear the same size as you see above.