ARMO named in Gartner® Cool Vendors™ report
We are excited and honored to announce that we were selected as Gartner Cool Vendor...
Nov 7, 2023
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
A supply chain attack typically follows these steps.
The attacker obtains credentials by scanning YAML config files and dumping environment variables for secrets to access Git repositories.
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.
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.
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.
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.
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.
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.
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.
They steal access tokens to a version control system (such as Git) from a developer or a DevOps engineer.
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.
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.
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.
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.
Experience effective, end-to-end, from dev to production, Kubernetes protection:
Manage Kubernetes role-based-access control (RBAC) visually
Eliminate misconfigurations and vulnerabilities from your CICD pipeline – from YAML to cluster
Full Kubernetes security compliance in a single dashboard
We are excited and honored to announce that we were selected as Gartner Cool Vendor...
ARMO launched a new Kubernetes vulnerability relevancy and prioritization feature based on eBPF technology to...
Discover the importance of mapping attack paths in Kubernetes and learn how to effectively enhance...