Open source container orchestration systems like Kubernetes have gone mainstream. Businesses are moving toward cloud-native technologies, building applications in the cloud to maximize their scalability. While a recent survey indicated cloud-native adoption is increasing among organizations, it has also become a popular target for threat actors.
Cloud-native systems enable faster runtime and simplified management, allowing businesses to run cloud applications at scale. Like any technology that uses various interconnected tools and platforms, security should play a vital role in cloud-native computing.
Complex software systems tend to create opportunities for threat actors – and cloud-native systems are no exception. Cloud-native security adopts a defense-in-depth approach that divides the system into four different layers. These are the four Cs of cloud-native security.
The 4Cs of cloud-native security
Here are some of the most common issues found in the four Cs: Cloud, cluster, container and code.
Cloud Security
The cloud layer in this framework refers to the infrastructure that runs servers. Cloud service providers (CSPs) are responsible for setting up a secure cloud infrastructure. Still, businesses must understand the shared responsibility model for cloud security. The model requires businesses to check and configure these services to maintain the security of their data that lives within the cloud services.
Shared Responsibility Model for Cloud
The most common issues found in today’s cloud systems are misconfigurations and challenges with automation.
- Misconfiguration issues—Misconfigurations are the most well-known challenge of cloud security. These are simple configuration mistakes that can be taken advantage of by cybercriminals, costing businesses revenue and reputation. Many services and applications are created with default settings that leave them exposed and vulnerable given the environment in which they are running. With the growing variety of cloud architectures, the risk of misconfiguration increases, inevitably creating opportunities for threat actors.
- Automation loopholes—When creating new systems and deploying new applications, automation can be ideal for improving speed and efficiency. However, it can also propagate errors and security issues much faster if they are not properly checked and monitored. Organizations must be able to secure the different facets of their architecture properly and efficiently.
Following CSP recommendations and regularly auditing settings can ensure proper configuration before deploying to production. Infrastructure-as-code (IaC) practices are also effective in minimizing misconfigurations. IaC is the standard today for building in the cloud, with the added benefit of helping DevOps teams get the most out of their cloud deployments while remaining secure.
Cluster Security
Kubernetes is the most widely adopted container orchestration tool, so it is our main focus when thinking about securing clusters. There are three main elements organizations should focus on when managing the clusters:
- Weak access control to cluster components. In the world of Kubernetes, a cluster consists of a set of worker machines, called nodes, that run containerized applications. The worker nodes host the pods that make up the application workload. A control plane manages the worker nodes and the pods in the clusters. Weak access control is one of the key security issues when managing clusters. Things like controlling API server access and restricting direct access to etcd should be essential when deploying a new cluster.
- Improper cluster service configurations. Proper configuration and access control for servers running in the cluster should follow the same logic. A recommended best practice is to set up an access-allow list to restrict access and run clusters with least-privilege principles. Kubernetes has a comprehensive document that discusses how to protect clusters from accidental or malicious access. Also, it is crucial to set up proper authentication and authorization to clusters, encrypt traffic using transport layer security (TLS) and protect sensitive information using secrets.
- Poor cluster networking. Communication between containers, pods and services requires strict control as well. 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 using network policies.
Container Security
Container runtime engines (CREs) are needed to run the containers in the cluster. Docker was the most popular of the CREs before Dockershim was deprecated, but Kubernetes also supports others such as containerd or CRI-O. There are three areas organizations often overlook in this layer.
- Loose image security. Containers should be updated to protect them from major vulnerabilities that could be exploited by a third party. 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.
- Unknown sources. It is crucial to ensure the image being used in the container is built by known sources or from known registries. Using image signing tools such as TUF or Docker Content Trust (DCT) to sign images and maintain a system of trust for the content of containers is a recommended best practice.
- Weak privileges settings. Containers should only run with users that have the minimal OS privileges necessary to carry out their tasks. It’s a bad idea to run privileged containersor containers with all the root capabilities of a host machine.
Code Security
The code or application layer is where organizations have the most control. Security risk can be simply managed by restricting and monitoring exposed services, ports and API endpoints. All communication should use TLS encryption, even between internal services, to add further security to the application layer.
Here are a few common issues in this layer that should be reviewed:
- Insecure code. Static code analysis (SCA) is one of the best and quickest ways to detect security issues within code. Having at least one static analysis tool embedded in the development pipeline that checks for unsafe coding practices each time developers commit new code is recommended.
- Inadequate application risk assessment. Automated scans and checks should be performed regularly to test for common application attacks such as SQL injection, cross-site scripting (XSS) and cross-site request forgery (CSRF) to ensure the applications are resilient against attackers.
- Risk of software dependencies. Between 70% and 90% of all cloud-native applications are made of libraries or have third-party dependencies. These are chunks of code, probably written by third party, running and embedded in the application. These are generally not checked during the static analysis phase. Using tools like the OWASP dependency check to check outdated or vulnerable libraries is recommended.
Security controls at each layer are very important to ensure cloud-native applications are not vulnerable to attacks. Each layer provides its own attack surface and may not be protected by the other layers, which is why a defense-in-depth approach is recommended.
Cybersecurity defenders need to cover every possible scenario and protect systems in every possible way. It is vital that businesses understand how to leverage third-party tools and managed services to improve the resilience of their containers and cloud-native applications. By closing the gaps and leaving no vulnerability between layers, attackers have little opportunity to jeopardize business operations.
To hear more about cloud-native topics, join the Cloud Native Computing Foundation and cloud-native community at KubeCon+CloudNativeCon North America 2021 – October 11-15, 2021
