Original source: theserverside.com (June 2019). Some CVE details and tool descriptions are drawn from the original article and public vulnerability databases.
Background: Jenkins X and the Continuous Delivery Foundation
In March 2019, the Linux Foundation launched the Continuous Delivery Foundation (CDF) as a vendor-neutral home for open source CI/CD projects. As part of that launch, Jenkins X was introduced as an opinionated CI/CD platform built specifically for Kubernetes, designed to automate the build, test, and deployment of containerised cloud-native applications.
Jenkins X integrates several well-known tools from the cloud-native ecosystem to deliver a complete pipeline experience on Kubernetes. Understanding those tools — and their associated security considerations — is essential before you roll Jenkins X into production.
Key Tools in the Jenkins X Ecosystem
Jenkins X orchestrates multiple open source tools. A working knowledge of each one helps you harden the right layers of your cluster.
Tekton
Tekton is a set of open source, Kubernetes-native components for building CI/CD pipelines. It models pipelines as Kubernetes Custom Resource Definitions (CRDs), making pipelines first-class Kubernetes objects. Tekton supports deployment targets including multi-cloud environments, virtual machines, bare-metal servers, and mobile platforms.
Spinnaker
Originally created by Netflix and subsequently co-maintained by Netflix and Google, Spinnaker is an open source, multi-cloud continuous delivery platform. It supports major cloud providers including Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), Amazon EC2, OpenStack, and Oracle Cloud Infrastructure.
Skaffold
Skaffold is a Google container tool that facilitates continuous development of Kubernetes-based applications using the Kubernetes CLI. Developers can iterate on source code locally and then deploy to local or remote Kubernetes clusters. Skaffold handles the build, push, and deploy workflow and integrates with Helm for release management.
Kaniko
Kaniko is another Google container tool. It builds container images from a Dockerfile inside a Kubernetes cluster — without requiring a Docker daemon. A Kubernetes secret must be created to authenticate to the target container registry (such as Google Container Registry). A Kaniko pod spec requires three key parameters:
- Dockerfile — the text file that defines the container image (no Docker daemon is used at runtime).
- Build context — typically retrieved from a Google Cloud Storage bucket or a Git repository.
- Registry — the destination registry where the final image is pushed.
Helm
Helm is the package manager for Kubernetes, maintained by the Cloud Native Computing Foundation (CNCF) in collaboration with Google, Microsoft, and Bitnami. In Helm 2 (the version current at the time of this article), Helm consisted of two components: a helm client that runs outside the cluster, and a Tiller server-side component that runs inside the cluster and manages chart installations and application releases. (Note: Tiller was removed in Helm 3, released later in 2019.)
Why Kubernetes Security Hardening Matters Before Jenkins X
Jenkins X installs and configures a significant portion of your cluster automatically. If underlying Kubernetes or CNI vulnerabilities exist before installation, they can propagate into your Jenkins X environment and remain undetected. Performing a security hardening pass first — patching known CVEs, tightening network policies, and auditing service account permissions — gives you a clean, trusted baseline.
The National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD) is the authoritative public source for tracking Kubernetes-related CVEs.
Known Kubernetes CVEs to Address Before Deploying Jenkins X
The following CVEs were publicly disclosed and relevant at the time Jenkins X was introduced (early–mid 2019). Verify their current status against the NVD before acting on them in production.
CVE-2019-9946 — CNI Firewall Misconfiguration (High CVSS 3.0)
A firewall misconfiguration was discovered in the Cloud Native Computing Foundation’s Container Networking Interface (CNI), which underpins Kubernetes network plugins. An unauthenticated attacker could exploit this flaw to access the firewall and modify CNI port-mapping rules, potentially bypassing network isolation between pods.
Remediation: Update to CNI 0.7.5 and upgrade Kubernetes to version 1.11.9, 1.12.7, 1.13.5, or 1.14.0. Review and enforce network policies and access controls on firewall configuration.
CVE-2019-1002100 — Kubernetes API Server JSON-Patch DoS (Medium CVSS 3.0)
A crafted-patch vulnerability was found in the Kubernetes API Server. A low-privileged attacker could send a specially crafted json-patch request that causes the server to repeatedly consume memory and CPU resources. When resource exhaustion occurs, the API server becomes vulnerable to a denial-of-service (DoS) condition.
Remediation: Apply the patch releases provided for your Kubernetes minor version and enforce RBAC policies that restrict who can issue PATCH requests against the API server.
CVE-2019-5736 — runC Root Escape (High CVSS 3.0)
A critical vulnerability in the core runc container runtime allowed an attacker to overwrite the host runc binary and gain root-level access to the host operating system. The attack could be triggered by running a malicious container image or by exploiting an existing container to which the attacker had write access. This vulnerability affects any container runtime built on runc, including Docker, containerd, and CRI-O.
Remediation: Upgrade runc to version 1.0-rc6 or later (or update your container runtime package via your Linux distribution). Apply the fix as a priority before enabling workloads from untrusted image sources.
CVE-2018-18264 — Kubernetes Dashboard Authentication Bypass (Medium CVSS 3.0)
Earlier versions of the Kubernetes Dashboard contained an authentication bypass that allowed a low- or no-privilege attacker to use the Dashboard’s Service Account to read Kubernetes Secrets within the cluster. No user interaction was required and the exploit could be performed over the network, exposing all data accessible to the Dashboard Service Account.
Remediation: Upgrade the Kubernetes Dashboard to a patched version and apply the principle of least privilege to the Dashboard Service Account. Consider disabling the Dashboard entirely if it is not actively used, or place it behind an authenticated reverse proxy.
A Hardening Checklist for Jenkins X Deployments
Beyond the specific CVEs above, apply these general hardening steps before deploying Jenkins X:
- Upgrade Kubernetes to a supported, patched minor version before installation.
- Patch the container runtime (
runc, containerd, or CRI-O) to the latest stable release. - Update CNI plugins to versions that address known CVEs.
- Restrict Tiller (Helm 2) permissions — Tiller runs with broad cluster-admin privileges by default; scope its service account to the minimum required namespace. Better still, evaluate migrating to Helm 3, which removes Tiller entirely.
- Enable and enforce RBAC across all namespaces used by Jenkins X pipelines.
- Audit service account tokens — avoid mounting API tokens into pods that do not need cluster API access.
- Apply Pod Security Standards (or Pod Security Policies if on older Kubernetes) to restrict privileged containers.
- Enable network policies to isolate pipeline namespaces from application namespaces.
- Monitor the NIST NVD regularly for new Kubernetes and related-tool CVEs.
Conclusion
Jenkins X brings significant automation power to Kubernetes-based CI/CD, but that automation touches many layers of your cluster — networking, secrets, service accounts, and the container runtime. A thorough Kubernetes security hardening pass, including patching the CVEs documented above, is a prerequisite — not an afterthought — for a production Jenkins X deployment. Monitor the NVD continuously; new vulnerabilities will emerge after you go live, and maintaining a patched, well-configured cluster is an ongoing operational discipline.