Register for our next webcast - securing containers and Kubernetes with StackRox Save My Seat >
{ .link_text }}

Protecting Against Kubernetes Threats: Chapter 1 - Initial Access

In the past five years, modern application architecture and compute infrastructure have been dramatically transformed by Kubernetes, the production-grade, open-source container orchestration system that has become the de facto standard for automating the deployment and management of cloud-native applications. At the same time, the adoption of Kubernetes and its use for business-critical operations drives new security challenges that must be appropriately understood and addressed - namely an expansion of the infrastructure attack surface that exposes organizations to new threats. Several of these threat vectors are detailed in the first-ever Kubernetes attack matrix published by Microsoft and based on the MITRE ATT&CK framework of known tactics and techniques.

This blog post discusses the first threat vector – initial access – as part of a nine-part blog series, in which we will take a deep dive into each of the nine Kubernetes threat vectors across 40 attack techniques and include guidance on security best practices to mitigate these threats. We will also highlight whether the security controls that should be primarily used and configured to adequately protect against these threats reside within (1) Kubernetes itself, (2) cloud provider platform services, or (3) other cloud-native tooling such as container image registries, package management systems, or others. To comprehensively secure Kubernetes, organizations must protect both the infrastructure systems that underlie it and those that directly interface with it.

Where applicable, we will also describe how the StackRox Kubernetes Security Platform protects organizations from the threats that make up the Kubernetes attack matrix.

Initial Access

The first vector, or category of attacker tactic, in the Kubernetes attack matrix is Initial Access. This tactic references the attacker’s objective of gaining access to Kubernetes clusters by either compromising a component within the Kubernetes control plane that handles cluster management or various resources within the cluster – for example, a running application component on a worker node.

Container and Kubernetes security evaluation guide

Download this guide that identifies some of the key security practices and controls you should implement to protect your containers and Kubernetes

Download Now

Technique 1.1: Using Cloud credentials

Issue

An attacker who gains access to cloud provider account credentials can use those to compromise entire Kubernetes clusters, whether running on managed Kubernetes platforms offered by cloud providers or administered by the customer on cloud compute instances.

Best Practice for Mitigation

Primary area to configure security controls: Cloud Provider

Organizations can mitigate this threat by configuring cloud provider identity and access management (IAM) services to restrict access to these account credentials, applying the principle of least privilege, and also ensuring that these credentials are rotated regularly. The use of shared credentials should be minimized, meaning IAM privileges should be granted to individual users rather than relying on shared accounts.

Technique 1.2: Compromised images in registry

Issue

Unsafe or compromised images that were either (1) downloaded from a public image registry or (2) which were added to a private registry and used to launch containers can result in an attacker gaining access to a cluster.

Real-world example: Backdoored container images that contained malicious code for mining the Monero cryptocurrency were publicly available on Docker Hub and downloaded more than five million times.

Best Practice for Mitigation

Primary area to configure security controls: Other - Image registry

To protect against this threat, organizations can implement multiple controls that include only allowing images from trusted registries to be used, whitelisting images from public registries such as Docker Hub, restrict access to trusted and/or private registries, and requiring developers to only use trusted base images when building containerized applications.

How StackRox Helps

The StackRox Kubernetes Security Platform can automatically enforce policies on what images can be used to launch containers and can also identify security issues, including vulnerabilities and problematic packages, in image layers separate from the underlying base operating system (OS) image. It provides visibility and analysis by enumerating these contents of images. StackRox also automatically monitors runtime activity to detect known bad processes that execute within pods such as processes meant to carry out cryptomining.

Technique 1.3: Kubeconfig file

Issue

kubeconfig is used by kubectl and contains the location and credentials of clusters. A compromised client could issue commands to gain unauthorized access to this file.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

Organizations should ensure the Kubernetes clients that end users are running to issue these commands, including kubectl, are updated to the latest version available. They should also configure the Kubernetes API server to use a third-party authentication provider rather than relying on static client certificates or other credentials that can be easily exploited.

Technique 1.4: Application vulnerability

Issue

Containerized applications that are public-facing can allow initial attacker access, and if these containers have vulnerabilities, they leave organizations susceptible to exploits. For example, a remote code execution (RCE) vulnerability could be exploited and since service account credentials are mounted to containers by default in Kubernetes, these credentials could then be used to make requests to the Kubernetes API server. More generally, exploiting a vulnerability may also allow an attacker to reach other applications, access the kubelet read-only API server, access sensitive data stored on cloud provider instance metadata servers, cause a denial of service attack, or other malicious activities.

Real-world example: CVE-2014-3120 is a RCE vulnerability in ElasticSearch that has been observed to have been used to breach a Docker environment in the wild.

Best Practice for Mitigation

Primary areas to configure security controls: Kubernetes and Cloud Provider

Kubernetes

Organizations should start by scanning their container images for vulnerabilities and configuring Kubernetes Network Policies to restrict external access to pods within a cluster. Admission control can be used to prevent containers with known high-severity vulnerabilities from launching.

Additionally service account permissions should be restricted using Kubernetes Role-Based Access Control (RBAC) according to the principle of least privilege. Service accounts should be unique to workloads, and administrators should ensure that workloads do not mount service account tokens unless they are needed to access the Kubernetes API server.

Pods should be further secured by only allowing non-root users, enabling a read-only root file system, and minimizing access to the underlying host.

Cloud Provider

If running on a cloud provider platform, controls such as Google Kubernetes Engine’s (GKE) metadata concealment, Workload Identity, or equivalent options should be enabled to prevent compromised pods from being leveraged to access cloud resources.

How StackRox Helps

StackRox scans container images for vulnerabilities as they are built and provides the option to fail CI/CD builds based on whether images violate specific policies including if certain vulnerabilities are present. The platform also enables users to quickly discover new vulnerabilities in running Kubernetes Deployments. StackRox also enables dynamic admission control to prevent containers with specific vulnerabilities from launching.

StackRox can automatically configure Kubernetes Network Policies based on observed network traffic to restrict external access to pods. It also automatically monitors Kubernetes RBAC configurations to help users identify risks and security weaknesses related to access settings.

Finally, StackRox can enforce policies to secure pods such as only allowing non-root users and configuring read-only root file systems.

Technique 1.5: Exposed Dashboard

Issue

The Kubernetes Dashboard is a web-based user interface that can be used for managing cluster resources. It exposes an internal endpoint and if accessible publicly, it can allow unauthenticated cluster management. Certain versions of Kubernetes platforms may deploy the Dashboard by default.

Real-world example: The car company Tesla experienced a breach of its Amazon Web Services (AWS) infrastructure due to a Kubernetes Dashboard that was exposed to the Internet and did not require authentication. The Dashboard further had elevated privileges on the cluster and allowed attackers to obtain AWS credentials that were then utilized to repurpose the environment to mine cryptocurrency.

Best Practice for Mitigation

Primary area to configure security controls: Kubernetes

If the Dashboard is not needed, administrators should ensure that it is deleted from the environment entirely or disabled (which is now generally the case for many Kubernetes platforms). If the Dashboard needed and is deployed, then do not grant it elevated service account privileges, remove any bindings to its service account, and block ingress traffic using Kubernetes Network Policies.

How StackRox Helps

StackRox provides a built-in policy to alert when the Kubernetes Dashboard is deployed. It also automatically monitors RBAC privileges on service accounts and can identify whether elevated privileges have been granted to the Dashboard. It can also ensure incoming traffic to the Dashboard is blocked by configuring Kubernetes Network Policies.