alcide

Alcide Blog

Cloud-native Security Provider

Kubernetes Threat Vectors: Part 1 - Initial Access

Oct 21, 2020 8:06:13 AM / by Alon Berger

Kubernetes keeps transforming the way we think about modern application architecture, as it keeps its status as the flagship orchestrator for containerized workloads and services.

With Kubernetes adoption on the rise, new security challenges and threats are even more common, and the potential risks must be taken into account.

Following our previous blog on Cloud Native Security for Kubernetes In Practice and as part of the National Cybersecurity Awareness Month happening now during October, we are breaking down the Kubernetes attack matrix, published by Microsoft and originally based on the MITRE ATT&CK framework. We will review each threat vector and its associated tactics and techniques. In this blog post, we are covering the first threat vector - Initial Access.

 

What is Initial Access?

The first objective for any type of attacker is to gain access. The Initial Access tactic describes how an attacker would find its way to infiltrate the victim’s containerized environment through the Kubernetes cluster and its resources. Such access can be achieved directly via the cluster management layer, or by gaining access to a malicious/vulnerable resource that is already deployed on the cluster.

Let’s review the different techniques:

  • Stolen cloud credentials

    Today, Kubernetes is widely used on managed services platforms like Amazon EKS, Google GKE, and Azure AKS. While moving to a managed cloud platform enables organizations to overcome challenges, such as large gaps in knowledge and relevant skill-set for running Kubernetes deployments, it can also leave an open door for an attacker to acquire the credentials for the cloud provider account. From this point, it is a matter of time until the Kubernetes clusters are compromised and taken over.

    How to mitigate?

    Once an attacker gets a hold of the relevant credentials or access tokens, he/she can easily get access to the cluster’s management layer. Probably the best way to handle these assets responsibly is to use the provider’s identity and access management services, or IAM in short. Using this framework of policies ensures that only authorized personnel in an organization have the appropriate access to various assets and resources.


  • Compromised images in the registry

    A container image is essentially a file gathering multiple code layers, required for running applications in a single instance or an isolated process.
    A compromised image might be the result of changing/modifying the image itself, after it was uploaded to the image registry and marked as trusted.

    Running a compromised image in a cluster is extremely harmful, as attackers with access to the private registry can alter those images and have them include vulnerable elements that can be exploited when the image is pulled and used to build a container.

    How to mitigate?

    In order to avoid using compromised images, a specific set of controls must be in place.
    Such controls should basically whitelist only the trusted image registries. Implementing these validation rules and restrictions will significantly minimize the risk of using corrupted or potentially compromised image files. Additionally, it is essential to make sure that images are pushed through dedicated CI plugins, as well as performing periodic image scans on early stages.

 

  • Kubeconfig file

    The kubeconfig file is primarily used to configure access to a Kubernetes cluster.
    Used by the kubectl command, this file contains details about the clusters, including locations and credentials. Gaining access to this file via a compromised client can lead to the execution of malicious shell commands, exposure of local files and leakage of credentials and SSH keys.

    How to mitigate?

    First, it is highly recommended to make sure that clients and end-users are updated with the latest version available. Furthermore, the Kubernetes API server should be configured to allow the use of third-party tools for validating files, exec commands and file directories.
    Another important practice is to simply store the kubectl config and the context list file in separate locations. This allows you to use a different set of contexts when overriding the kubeconfig variable, instead of overriding the kubectl settings. It is also an accepted practice among managed services providers to offer kubeconfig files, downloaded by the user and later selected as an environment variable.

 

  • Vulnerable applications

    Public-facing applications are an easy way for an attacker to exploit many vulnerabilities.
    Such weakness can be a bug, a glitch or a design vulnerability. Many of these applications are often websites, however, they can include databases, open sockets and other related services that can contain sensitive information.If an application is hosted on cloud-based infrastructure, then exploiting it may lead to compromising of the relevant instance, and reach sensitive data that is stored there. This can allow an adversary a path to access the cloud APIs or to take advantage of weak identity and access management policies.

    Such applications can be easily exploited by techniques like remote code execution (RCE), enabling adversaries to leverage network misconfigurations to get a hold of service account credentials. After obtaining these credentials, the attacker is able to perform requests to the Kubernetes API server, which might lead to a Denial of Service (DDoS) attack.

    How to mitigate?

    First and foremost, always make sure to perform periodic scans, ideally with a multi-cluster vulnerability scanner, like the Alcide Advisor for example.
    Running such scans on early stages will detect those weak points and will allow you to completely block all communication to and from those points.
    Another key aspect in the permission domain is to use Role-Based Access Control (RBAC), primarily for minimizing privileges.
    Additionally, the admission control can be used as another “gatekeeper”, preventing the launch of corrupted containers with high severity scoring.

 

  • Exposed Kubernetes dashboard

    This web-based user interface allows the user to monitor, troubleshoot and manage the cluster resources. It offers an overview of running applications, providing visual information for the different moving parts.




















    By default, the dashboard exposes an internal endpoint (ClusterIP service).
    If the dashboard is exposed externally, it can allow unauthenticated remote management of the cluster. The conception here is that everything that can be done using kubectl can be done using the dashboard, making it a major weak point by default.


    How to mitigate?

    First, ask yourself whether the Kubernetes dashboard is even necessary in your daily operations routine. If not, you can easily disable or delete it from your environment.
    If the dashboard is your friend and you wish to keep it around, simply make sure you are using updated versions and enforcing authorized-only access by end-users with relevant tokens and kubeconfig files.

 

How can Alcide help?

After covering the first attack vector, we can see that with continuous end-to-end scanning and security guardrails, you will be able to secure your Kubernetes deployments and workloads, detecting any of the mentioned threats as early as possible.

The Alcide Advisor is an essential tool for scanning your clusters for the known and unknown vulnerabilities. The dynamic analysis provides a snapshot of potential risks, misconfigurations and hygiene drifts, indicating on tainted CI/CD pipelines.

Alcide’s platform and the solutions it offers enable both DevOps and security teams to easily monitor and maintain healthy environments, focusing on Kubernetes clusters.

 

Topics: cloud security, kubernetes, Kubernetes security, cloud

Subscribe to Email Updates