Alcide Blog

Cloud-native Security Provider

Kubernetes Threat Vectors - Part 7: Discovery

Jan 6, 2021 9:36:48 AM / by Alon Berger


Welcome to our seventh blog post on the Kubernetes threat vectors series.

We are covering different tactics on the Kubernetes attack matrix, published by Microsoft and originally based on the MITRE ATT&CK framework. In this blog post, we will review the Credential Access tactic, and cover its techniques.

What is Discovery?

The credential access tactic consists of techniques that are used by attackers to explore the environment to which they gained access. This allows the attackers to observe and learn the network, enabling them to perform lateral movement and gain access to additional resources.


Let’s review the different techniques:

  • Access the Kubernetes API server

    All actions in the clusters are performed by communicating with the Kubernetes API server, which serves as the gateway for the Kubernetes control plane. Once exploited, attackers may send API requests to probe the cluster and get information about containers, secrets, and other resources in the cluster.

    How to mitigate?

    It is highly recommended to block connections between the cluster and the API server, leveraging Kubernetes RBAC to ensure limited access and permissions for trusted users and service accounts. 


  • Access Kubelet API

    Kubelet is the Kubernetes agent that is installed on each node, responsible for the proper execution of pods that are assigned to the node. Kubelet exposes a read-only API service that does not require authentication. Attackers who gained network access to the host by running their code on a compromised container can communicate directly with the Kubelet API. This exploit can lead to the extraction of pods running on nodes, and general information about the node itself.

    How to mitigate?

    Mitigating this threat comes down to configuring granular API and network policies across the entire environment, including multi-cluster service communications. Also, implementing automated analysis tools like Alcide kAudit for monitoring Kubernetes audit logs, enables security teams to quickly detect and alert on any suspicious and unauthorized activity.


  • Network mapping

The network mapping technique takes advantage of the fact that by default, there are no restrictions on pods communication in Kubernetes. With that in mind, attackers may try to map the cluster network to get information on the running applications, including scanning for known vulnerabilities.

How to mitigate?

Similar to the previous technique, mitigating this threat also revolves around hardening Kubernetes network policies, enforcing traffic segmentation between pods.
In addition to Alcide’s kAudit module that monitors and analyses Kubernetes audit logs, kArt provides Kubernetes microservices at scale. With a network-based approach, kArt helps with cloud-native security policies along with image scanning and vulnerability management in runtime, highlighting potentially vulnerable Kubernetes components.


  • Access Kubernetes dashboard

    The Kubernetes dashboard 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 for 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.

  • Instance Metadata API

    All cloud providers provide instance metadata service for retrieving information about the virtual machine, such as network configuration, disks, and SSH public keys. This service is accessible to the VMs via a non-routable IP address that can be accessed from within the VM only. Attackers who gain access to a container, may query the metadata API service for getting information about the underlying node.

  • How to mitigate?

    Organization should always ensure proper configurations of network policies including egress, thus strictly limiting communications with cloud metadata services.
    Furthermore, administrators can intercept compromised pods that might be used towards accessing other cloud resources by using tools like Google's Workload Identity for GKE deployments.


How Alcide Helps

Alcide’s platform keeps the entire dev-to-production pipeline secured with enhanced Kubernetes security capabilities, specifically designed for the most complex environments.
With Alcide, tackling various challenges and potential threats like the Discovery tactics is easily achieved by:

  • Identifying abnormal administrative and network activity 

  • Preventing abuse of the Kubernetes API

  • Identifying and alerting on scanning attempts 

  • Verifying access policies for your dashboard

  • Ensuring proper isolation of your virtual machines and hosts

Stay tuned for our next chapter, where we will review the eighth tactic - Lateral movement.

Want to give Alcide a try? Sign up for our 14-day trial to fully experience our platform.



Subscribe to Email Updates