Microsoft warns that while deploying Kubernetes, it can use pre-made templates such as out-of-the-box Helm charts to open the door to misunderstanding and leak valuable data.
“These ‘plug and play’ options greatly simplify the setup process, but in many cases they prioritize ease of use over security,” says Michar Katchinskiy and Yossi Weizman of Microsoft Defender for Cloud Research Team.
“The result is that many applications will be deployed incorrectly by default, exposing sensitive data, cloud resources, or the entire environment to attackers.”
Helm is a Kubernetes package manager that allows developers to package, configure, and deploy applications and services into Kubernetes clusters. It is part of the Cloud Native Computing Foundation (CNCF).
A Kubernetes application package consists of a helm package format called a chart. This is a YAML manifest and template used to describe the Kubernetes resources and configuration required for app deployment.
Microsoft pointed out that open source projects often include default manifests or predefined helm charts that prioritize ease of use over security, leading to two major concerns in particular.
Rack by default for proper built-in authentication or authorization to expose services from outside without proper network restrictions
As a result, organizations using these projects without reviewing the YAML manifest or helm chart will inadvertently expose their applications to attackers. This can have serious consequences if deployed applications facilitate queries for sensitive APIs or allow management actions.
Some of the identified projects that could put a Kubernetes environment at risk of attacks are:
Apache Pinot, which exposes the main components of OLAP Datastore, Pinot-Controller and Pinot-Broker to the Internet via Kubernetes Loadbalancer Services, is now available to access IP addresses and new users by exposing the app’s interface through an external IP address, without authentication, by default, without authentication. Code execution selenium grid. This exposes node port services to a specific port across all nodes in a Kubernetes cluster, and makes external firewall rules the only line of defense
To mitigate the risks associated with such misconceptions, we recommend reviewing and modifying security best practices, periodically scanning for face-to-face interfaces, and monitoring your running containers for malicious and suspicious activity.
“In many cases, when using default settings, the internal use of many containerized applications often comes from misunderstood workloads,” the researchers said. “Relying on a ‘Defal by Concent’ setup poses a serious security risk. ”
Source link
