Insecure Defaults Remain a Threat for Kubernetes
Secure-by-default settings make it easier (and safer) to onboard cloud-native technologies. And, thankfully, most default security profiles and configurations are, often, quite solid. Take Istio, which is secure by default and built with zero-trust in mind. Other environments, however, are not as well-guarded.
A new report by Accurics, the Cloud Cyber Resilience Report, found that insecure defaults make up nearly half of security violations in Helm charts commonly used within Kubernetes. The report also reveals that 1 in 4 security violations can be traced to poorly configured managed service offerings.
Let’s dig into the key findings of the report below. We’ll identify common frailties among Kubernetes ecosystems and outline some security implications of using managed services in cloud-native architecture.
Analyzing the Strength of the Kubernetes Ecosystem
The report examined infrastructure-as-code (IaC) used to provision cloud components, and flagged violations against CIS benchmarks.
The study analyzed Helm charts for popular prepackaged components within Kubernetes, such as Bitnami, HashiCorp, Jenkins, Harbor, AWS and others. To put your mind at ease, not many violations were found in these popular repositories. “The Kubernetes community appears to be doing an admirable job of avoiding these problems,” the report notes. However, there’s always room for improvement.
Out of the problems that were found, 47.9% of violations were due to insecure defaults — the most common type being improper use of the default namespace.