GitLab security scanning – part 3: Kubernetes deployments

No Comments

In part 1 and part 2, we focused on different types of security scanning practices. In this article we will take a look at Kubernetes deployments with Helm and Helmfile. In particular, we are interested in how to ensure that objects deployed to Kubernetes follow security best practices.

1) Scanning Helm Charts

Let’s first look at how security best practices can be ensured in deployments of Helm Charts using GitLab pipelines. As described in helm charts, Helm Charts summarise YAML manifest files in a specific format. In particular, these manifests describe deployments, StatefulSets or other Kubernetes objects that ultimately create pods in Kubernetes. For pods to run securely in Kubernetes, pod and container definitions, among other things, must define certain properties. For example, the SecurityContext should be set as restrictively as possible and ServiceAccounts should be used for pods. GitLab uses kubesec for scanning Helm Charts. Now let us look at the directory structure:

The root directory contains the .gitlab-ci.yml file. Parallel to this is the directory helm-chart, which contains the helm chart vuln-project. This path must be given to the pipeline as variable KUBESEC_HELM_CHARTS_PATH (line 8). To enable kubesec analyzer, set SCAN_KUBERNETES_MANIFESTS: "true". Scanning a Helm Chart is one of the static analyses. Therefore, it can be activated by inserting the SAST job (line 2+3).

Once the sources have been committed and pushed to the GitLab server, kubesec starts analysing.

GitLab Security Helm Chart Pipeline

GitLab then reports any vulnerabilities found in the security tab of the pipeline:

GitLab Security Helm Chart Vulnerabilities

Details of vulnerabilities found and links to further information can be found in the popup window:

GitLab Security Helm Chart Vulnerability Details

Findings can be rated in the pop-up window in the same way as in the overview. If this assessment requires mitigation, an issue can also be created here for tracking.

2) Scanning Helmfiles

As seen in Part 1 of this article, GitLab natively supports security scanning of Helm Charts. For the declarative deployment of Helm Charts with Helmfile, this support is missing. However, to still be able to check Helmfile sources for vulnerabilities, a small additional step is sufficient. Let’s first look at the directory structure:

Again the root directory contains the .gitlab-ci.yml file. The helmfile.yaml file contains the inclusion of the various stages from the env directory and defines which objects are installed. In order for SAST to have files for a security analysis, Helmfile must first be executed. This happens in the .gitlab-ci.yml in an additional job build_helm_manifests (line 5-16). This job creates a directory $CI_PROJECT_DIR/k8s-manifests and updates the helm repos used. Subsequently, helmfile template --output-dir $CI_PROJECT_DIR/k8s-manifests generates YAML manifests (lines 10-12). In order for these generated files to be passed to the kubesec-sast job for analysis, these manifests are stored in an artifact (lines 14-16). In order for the kubesec-sast job to access the artifacts, it is given a dependency on the build job (lines 19-21). Finally, the kubesec analyser must be activated with SCAN_KUBERNETES_MANIFESTS: "true" (line 29) and by inserting the SAST job .gitlab-ci.yml (line 24+25).

The pipeline starts as soon as the code is pushed to GitLab. As expected, two jobs are now running one after the other to create the artifact and to run the security scanning procedures.

GitLab Security Helmfile Pipeline

After the security scan has been completed, the findings can be viewed in the vulnerability report. Here it is possible to apply various filters to the results and sort them if necessary. Details about vulnerabilities can be displayed via links within the findings.

GitLab Security Helmfile Vulnerabilit Report

Summing up

GitLab can also scan deployments to Kubernetes for security best practices using tolls such as Helm Charts or even Helmfile. If vulnerabilities are discovered, they can be fixed before deployment.

This article concludes the series of articles (GitLab security scanning – part 1, GitLab security scanning – part 2) on security scanning with GitLab.

Sven Hertzberg is creating and operating distributed software systems and infrastructures. In his current role as a Cloud Engineer, he builds different highly available systems based on cloud technology for cc cloud GmbH and its customers.


Your email address will not be published.