The advent of Infrastructure-as-Code (IaC) and cloud platforms has transformed applications into ephemeral deployments of configuration files, where containers live for only a few minutes. Several industry-level static analyzers are available to check security misconfigurations before deployment, but the experimental evidence that we report in this paper is that they provide different and possibly inconsistent results. We developed an automated pipeline to evaluate and compare static analyzers for Helm charts, a popular package manager to deploy Kubernetes (K8s) applications, in finding a functional configuration adhering to the principle of least privilege. We evaluated seven open-source chart analyzer tools on the 60 most common Artifact Hub Helm charts (returned by the Application Programming Interface — API upon first invocation) and found that overly permissive ClusterRoles are the most common misconfiguration, and using a high user ID is the most commonly needed permission. During the evaluation, we also found several bugs, both false positives and negatives, that we reported to the tool developers. Securing cloud configurations still requires significant manual intervention, and more effort should be spent on standardizing the analysis of misconfiguration.

Helm is a package manager that allows defining, installing, and upgrading applications with Kubernetes (K8s), a popular container orchestration platform. A Helm chart is a collection of files describing all dependencies, resources, and parameters required for deploying an application within a K8s cluster. This study aimed to mine and empirically evaluate the security of Helm charts, comparing the performance of existing tools in terms of misconfigurations reported by policies available by default, and measuring to what extent LLMs could be used for removing misconfigurations. For these reasons, we proposed a pipeline to mine Helm charts from Artifact Hub, a popular centralized repository, and analyze them using state-of-the-art open-source tools like Checkov and KICS. First, the pipeline runs several chart analyzers and identifies the common and unique misconfigurations reported by each tool. Secondly, it uses LLMs to suggest a mitigation for each misconfiguration. Finally, the LLM refactored chart previously generated is analyzed again by the same tools to see whether it satisfies the tool's policies. We also performed a manual analysis on a subset of charts to evaluate whether there are false positive misconfigurations from the tool's reporting and in the LLM refactoring. We found that (i) there is a significant difference between LLMs, (ii) providing a snippet of the YAML template as input might be insufficient compared to all resources, and (iii) even though LLMs can generate correct fixes, they may also delete other irrelevant configurations that break the application.

The adoption of microservice architecture is rapidly growing, involving industries of every size. Their ability to scale and reconstitute complex functionalities into small, cohesive, and interconnected components (the microservices), and their limited use of isolation contribute to this success. Unfortunately but unsurprisingly, these very factors enlarge the attack surface and increase the security risks of today’s deployments. In this study, we performed a systematization of knowledge about the run-time security of microservices. Starting from a keyword search, we initially reviewed 807 papers available in digital libraries (e.g., Google Scholar and Scopus), which we filtered down to 48 by applying a number of selection criteria (e.g., the presence of a proof-of-concept implementation). We also considered over 30 industry tools that offer various security services for microservices. We categorized both papers and tools and highlighted areas where research is abundant, where it is lacking, and where it is misleading. We conclude that the run-time security of microservices is still in its infancy and we supplement our analyses with insights into addressing the key challenges.

Securing cloud configurations is an elusive task, which is left up to system administrators who have to base their decisions on "trial and error" experimentations or by observing good practices (e.g., CIS Benchmarks). We propose a knowledge, AND/OR, graphs approach to model cloud deployment security objects and vulnerabilities. In this way, we can capture relationships between configurations, permissions (e.g., CAP_SYS_ADMIN), and security profiles (e.g., AppArmor and SecComp). Such an approach allows us to suggest alternative and safer configurations, support administrators in the study of what-if scenarios, and scale the analysis to large scale deployments. We present an initial validation and illustrate the approach with three real vulnerabilities from known sources.

The use of container and orchestration technologies, such as Docker and Kubernetes keeps growing every year. For the purpose of security experimentation and reproducibility of security attacks and defenses, an open-source testbed would also be an important step forward. Yet, while several security experimentation testbeds from web application testing to capture-the-flag (CTF) competitions have been proposed, a similar solution for cloud experiments is wanting. To fill this gap, we propose an open-source cloud testbed that, by using Domain Specific Language (DSL) files (e.g. with JSON or YAML syntax), allows defining experimentation scenarios as configuration files. Using DSL files allows to create, share, customize, automatically deploy, and reproduce different scenarios in a user-friendly manner. We describe the design and the corresponding tools and technologies for different implementations.