Top four Kubernetes Attack Chains and how to break them 

While Kubernetes adoption continues to soar, it has become a prime target for cyberattacks. Unfortunately, Kubernetes clusters are complex and can be difficult to secure. Safeguarding your Kubernetes environment requires a solid understanding of the common attack chains that pose a threat to your infrastructure. 

In this blog post, we dig into the top attack chains that target Kubernetes, shedding light on the risks and offering valuable insights to bolster your defenses.

Attack Path A: Exposed endpoint attacks

In this type of cyberattack, a malicious actor targets a Kubernetes cluster that has one or more of its endpoints exposed to the public internet. These endpoints can include the Kubernetes API server, the kubelet, or other services that are not properly secured. 

Once an attacker has gained access to an exposed endpoint, they can then use it to gain further access to the cluster, including its sensitive data and resources.

Attack chain

This attack chain scenario involves a public-facing containerized workload with a remote code execution vulnerability. This vulnerability can be likened to a backdoor, allowing attackers to infiltrate and take control of the containerized process. 

The steps involved in this scenario are as follows.

Step 1: Reconnaissance

The hacker probes the cluster network for public vulnerabilities and discovers an exposed workload with a remote code execution vulnerability. This workload could be a service used by the pod, or it could be an unsecured Kubernetes API server or kubelet that has anonymous access enabled by default.

When a workload in the cluster is left publicly exposed, the attacker can send API requests from the compromised workload to probe the cluster and steal sensitive information about other cluster resources.

Step 2: Exploitation

If the cluster uses default settings where the service account token is mounted to every created pod in the cluster, the attacker can access the token and use it to authenticate to the Kubernetes API server. This allows them to gain access to the resources and privileges of that service account.

Step 3: Lateral & Vertical Movement

The compromise deepens if the workload has mounted Kubernetes secrets; this is because the attacker would be able to retrieve these secrets from the Kubernetes API server and potentially gain access to high-value system information such as credentials.

Step 4: Exfiltration

If the workload is running on a privileged container, the attacker would gain access to the host’s resources and could then perform actions to access sensitive data and disrupt services.

If the workload has network access to system databases, the attacker can also exploit this advantage to manipulate or exfiltrate valuable data.

Countermeasures

The best way to mitigate the risk of an exposed endpoint attack is by using vulnerability management tools and processes to identify and patch code vulnerabilities and cluster misconfigurations.

To reduce the attack surface in case of this scenario, disable the service account auto-mount setting in the pod configuration. This will prevent the service account token from being mounted to every pod in the cluster, making it more difficult for hackers to probe the cluster and gain access to other cluster resources. 

Another countermeasure to mitigate the attack chain is to leverage firewalling to restrict network traffic between hosts using network policies; this will prevent attackers from probing the network and moving laterally within the cluster.

Lastly, secure the Kubernetes API server and kubelet by disabling anonymous access with the 

-anonymous-auth=false flag

User access to the API server should be authenticated via external authentication methods, such as OpenID Connect (OIDC), that are built into managed Kubernetes services like AWS EKS or Azure AKS.

Attack Path B: Privilege escalation attacks

A privilege escalation attack is when an attacker gains unauthorized access to privileged roles and resources in a Kubernetes cluster. This can be done by exploiting security flaws in the cluster environment, including overly permissive role-based access control (RBAC) policies or exposed pods.

Attack Chain

This attack chain involves exploiting the credentials of an exposed pod to gain higher privileges in the Kubernetes environment. The steps in this scenario are as follows.

Step 1: Reconnaissance

The attacker scans the cluster network for exposed pods using a port scanner, and finds an exposed pod that is mounted with a default service account token.

Kubernetes automatically creates a service account token for each namespace by default. If a pod is not manually assigned a service account when it is deployed to a namespace, Kubernetes assigns the default service account token of that namespace to the pod.

Step 2: Exploitation

The hacker infiltrates an exposed pod in the cluster with default settings where the service account token is mounted. The service account token provides a doorway for them to access the Kubernetes API server using the service account associated with the token.

Step 3: Lateral & Vertical Movement

If RBAC is not enabled or the RBAC policies associated with the pod are overly permissive, the attacker can use the compromised pod’s service account to create a new privileged container with admin permissions.

Step 4: Exfiltration

With admin permissions, the hacker can then create binding and cluster-bindings to the cluster-admin ClusterRole or other privileged roles, hence gaining access to all resources in the cluster.

Countermeasures

A key approach to reducing the attack surface is to use admission controllers to restrict the deployment of overly permissive containers in the cluster, including privileged containers and containers with mounted volumes containing sensitive data (such as Kubernetes secrets and cloud credentials). This prevents privileged containers from being deployed into the cluster, making it more difficult for attackers to maintain persistence in the cluster.

As Kubernetes credentials are usually retrieved or generated via API calls to the Kubernetes API server in a privilege escalation attack, the key approach in mitigating this risk is to apply the “principle of least privilege” when configuring Kubernetes RBAC policies for all accounts in the cluster environment. Ensure that each user or service account is configured with the minimal necessary permissions to access network resources, and restrict unauthorized users from creating privileged role bindings.

Besides implementing these countermeasures, it’s also important to conduct a periodic review of RBAC policies and roles to ensure there is no drift in privileges.

Attack Path C: Supply chain attacks

A malicious actor targeting the software supply chain could involve exploiting vulnerabilities in container images, application dependencies, or other components in the continuous integration and continuous delivery (CI/CD) pipeline used in building and deploying applications in Kubernetes.

Attack Chain

A supply chain attack typically follows these steps.

Step 1: Reconnaissance

The attacker obtains credentials by scanning YAML config files and dumping environment variables for secrets to access Git repositories.

Step 2: Exploitation

The hacker places malicious images in public container registries or injects malicious code inside benign images and infrastructure as code (IaC) configuration files; this way, they are essentially planting a digital Trojan horse within the software supply chain.

Step 3: Lateral & Vertical Movement

When an application in the cluster uses the compromised image, the attacker can perform malicious code execution to access all the cluster resources that the workload can access, such as secrets, ConfigMaps, persistent volumes, and networks.

Step 4: Exfiltration

Malicious actors can also divert computational resources toward illegitimate activities like cryptocurrency mining.

This type of attack is highly insidious, as it exploits the inherent trust developers place in public libraries, turning it into a tool of invasion.

Countermeasures

Mitigating the risk of a supply chain attack in Kubernetes involves securing components at every stage of the CI/CD pipeline. You can use automated vulnerability scanning in Git repositories and container images to uncover and remediate vulnerabilities before deployment. To ensure the provenance of images and prevent unintended use of compromised images in the application, make sure to verify image signatures so you know that the images used are the ones intended. 

At the continuous deployment stage, use Pod Security Standards and Pod Security Admission, or policy engines such as Open Policy Agent (OPA) and Kyverno, to prevent non-compliant images from being deployed. This can help to prevent malicious applications from being deployed in the cluster.

Attack Path D: Developer credentials theft

Developer credentials theft is a type of cyberattack in which a hacker steals the credentials of a developer or DevOps engineer who has access to a Kubernetes cluster. This could allow them to gain access to the cluster and its resources, including sensitive data and applications.

Attack Chain

In this fourth type of attack chain, a hacker impersonates the identity of a developer to gain access to the Kubernetes environment using the following steps. 

Step 1: Reconnaissance

After scanning the cluster network for exposed pods, the malicious actor finds an exposed pod. They then use the compromised pod to probe the cluster environment for access tokens in Kubernetes configuration files through the kubectl command. If the Kubernetes cluster is hosted through a cloud provider, the attacker queries the cloud metadata API to obtain cloud credentials and access the S3 bucket storing the IaC state files, which might contain sensitive information in plain text.

Step 2: Exploitation

They steal access tokens to a version control system (such as Git) from a developer or a DevOps engineer.

Step 3: Lateral & Vertical Movement

Equipped with these credentials, the hacker can impersonate the developer to alter code and steal secrets from the Git repository, especially if IaC is used to manage the cluster.

Step 4: Exfiltration

If the cluster leverages GitOps, which automatically pulls changes from Git, the attacker can introduce malicious workloads into the cluster through Git, leading to a full-scale compromise of secrets and data.

Countermeasures

To mitigate the risk of developer credentials theft, avoid using plain text credentials in configuration files. Also, use managed secret stores, for example, Hashicorp Vault or AWS Secrets Manager, to make sure your secrets and credentials are stored securely.

Conclusion

Understanding the common attack chains targeting Kubernetes is essential for safeguarding your environment against malicious actors. By staying vigilant, implementing security best practices, and leveraging the appropriate countermeasures, you can bolster your defenses and ensure the integrity of your Kubernetes deployments. 

Stay informed, regularly update your infrastructure, and adopt a proactive security stance to mitigate risks and protect your valuable workloads. ARMO Platform’s Attack Path functionality enables users to visualize the weaknesses available to malicious actors. Once visualized it highlights the steps in the path, where attacks can be blocked and guides engineers in the remediation steps. Learn more about ARMO Platform and how it will help you block attacks before they happen.