Perform a Kubernetes security hardening before you use Jenkins X

Source:- theserverside.com

In March 2019, the Linux Foundation created the Continuous Delivery Foundation as a vendor-neutral means for developers to track CI/CD open source projects. At the same time, the Continuous Delivery Foundation debuted Jenkins X, an open source CI/CD tool to automate Kubernetes and manage the integration and delivery of containers in cloud applications.

Kubernetes uses multiple software tools in CI/CD, including:

• Google open source tools Tekton and Spinnaker
• Google container tools Skaffold and Kaniko
• Open packaging manager Helm

However, before a developer uses Jenkins X on Kubernetes, they should be aware of multiple security vulnerabilities that can create issues in a deployment. A developer should perform a Kubernetes security hardening before they run Jenkins X to get the most secure and up-to-date version of the platform.

Let’s take a look at some software tools and then Kubernetes vulnerabilities to be aware of with Jenkins X.

Google open source tools

Tekton is a shared set of open source components that help build CI/CD systems. It provides deployment to Kubernetes, along with multi-clouds, VMs, bare metal and mobile. Tekton takes advantage of Kubernetes and shifts the software development there to modernize the CD control plane.

Spinnaker was originally created by Netflix, and is currently led by both Netflix and Google. It is an open source, multi-cloud continuous delivery platform that provides support for cloud providers like Google Kubernetes Engine, Azure Kubernetes Service, Amazon EC2, OpenStack and Oracle Cloud Infrastructure.

Google container tools

Skaffold uses Kubernetes’ command line interface tool for continuous development of Kubernetes containers. A developer can locally iterate source code and then choose to deploy it to local or remote Kubernetes clusters. Skaffold provides workflows to help DevOps teams build, push and deploy the application.  To make workflow tasks easier, Skaffold supports open packager manager Helm.

Kaniko is also a Google container tool. A user starts with the standard Kubernetes cluster, via the Google Kubernetes Engine, to build and push container images. Note that you must create a Kubernetes secret to authenticate to the Google Cloud Registry. The tool provides these three parameter arguments in a pod spec to run a container image:

• a Dockerfile, which is a text file that defines a Docker image. But note that the Docker Daemon isn’t involved in this instance;
• a build context, which is retrieved from a Google Cloud Storage bucket; and
• A registry, where the final image can be pushed.

Open package manager

Helm is a package manager tool for Kubernetes applications and is maintained by the Cloud Native Computing Foundation in collaboration with Google, Microsoft, and Bitnami. Helm comes in two parts: a (helm) client that runs outside the cluster and a (tiller) server that runs inside the cluster and manages application releases from within. The tiller also manages charts installations.

Kubernetes security hardening

Before you jump into Jenkins X, you should perform a Kubernetes security hardening to deploy, maintain and monitor Kubernetes clusters without issues. The National Institute of Standards and Technology and National Vulnerability Database website monitors Kubernetes vulnerabilities.

The following vulnerabilities should be corrected in your Kubernetes security hardening before you start with Jenkins X.

• CVE-2019-9946: A firewall misconfiguration was found in the Cloud Native Computing Foundation Container Networking Interface (CNI) that’s used for Kubernetes network plugins. This vulnerability would allow an attacker, without any privileges, to access the firewall and modify CNI port rules. This vulnerability comes with a high Common Vulnerability Scoring System (CVSS) 3.0 rating.
  • A developer can fix this vulnerability in CNI 0.7.5 and Kubernetes 1.11.9, 1.12.7, 1.13.5, and 1.14.0. The administrator should update network policies on firewall configuration and access controls.
• CVE-2019-10002100: A crafted patch vulnerability was discovered in the Kubernetes API Server (Red Hat). This vulnerability would allow an attacker, with low privileges, to potentially send a specially crafted “json-patch” to repeatedly consume resources. When excessive consumption exhausts all resources, the API server is vulnerable to a denial of service attack. It has a medium CVSS 3.0 rating.
• CVE-2019-5736: A root access vulnerability was found in the core runC container code that could let an attacker gain root access to the host operating system. For example, an attacker could use a new container with an attacker-controlled image or an existing container with attacker write access to execute a command as root. Also, an attacker has the ability to deny some availability to other users. It has a high CVSS 3.0 rating.
• CVE-2018-18264: An authentication bypass vulnerability was located in earlier versions of Kubernetes Dashboard. An attacker with no or low privileges can use Dashboard’s Service Account to read secrets with the cluster. No user interaction is required to exploit the vulnerability over the network, and all information in the Service Account is exposed. However, the vulnerability doesn’t result in a denial of service attack.  It has a medium CVSS 3.0 rating.

A developer should monitor security vulnerabilities at all times to ensure a secure deployment. A Kubernetes security hardening is one step toward a successful Jenkins X deployment.