Want to see Spyderbat in action?
Among organizations surveyed in 2022, 90% will have Kubernetes deployed in their environments in the next two to three years, more than half have already done so. As with most rapid adoption trends in IT, the curve of enthusiasm for new scalable capabilities – multi-cloud flexibility and greatly simplified development and deployment processes in this case – has opened a lead on practical measures to secure them. Currently, only 35% of organizations relying on Kubernetes have enacted protections against data loss to common attack types such as ransomware.
The hasty shift of enterprise IT away from individual Docker containers and into Kubernetes-orchestrated multi-cluster applications has not eluded the attention of threat actors. Security researchers have recently observed a significant parallel pivot in container-focused cyberattacks. From 2020 to 2021, the detection rate for malicious container images targeting Kubernetes in public repositories more than doubled, rising from 9 to 19% of target types. Reports from DevOps teams during the same time reflect these evolving threat activities. More than 90% report a Kubernetes security incident in the last year, with just over half – 55% – resulting in deployment delay.
Challenges in Kubernetes Security
Much of what drives the appeal of Kubernetes to developers also makes them inherently difficult to secure against attacks.
1. Multi-Cloud Distribution
Kubernetes run nearly effortlessly on multi-cloud and hybrid public-private cloud environments. While facilitated distribution creates resilience against individual server failures and reduces latency by relocating processing tasks closer to end-users, it comes at the cost of highly diminished runtime visibility. With traditional Linux monitoring tools such as AuditD, even optimal configuration – an impracticality in ephemeral environments – offers no help as such tools are container-blind.
2. Immutable Infrastructure
The ease of spinning and destroying Kubernetes and other containers on a whim has allowed developers to create a workaround for distributing changes and patches. Rather than tweak applications already running in Kubernetes – thereby running the risk of destabilizing them – developers simply destroy and create them again from immutable infrastructure templates. In practice, this rapid container-churn means security teams often don’t even know when developers spin new containers, leaving them unable to apply the same security standards they would with physical servers or virtual machines.
3. Minimal Default Configurations
Although highly configurable, Kubernetes are still an open-source container orchestration system. As such, they come to developers out-of-the-box with the least secured default configurations. In high churn environments, their post facto configuration rarely matters in operations as security teams lack sufficient time and resources to properly configure each one manually.
Holistic Cloud Security for Protecting Kubernetes with Spyderbat
Overcoming the security challenges Kubernetes posed in runtime environments requires resolving the seemingly intractable problem of gaining visibility into and across ephemeral containers. Spyderbat’s eBPF-based runtime monitoring platform provide security and platform teams with exactly this kind of glaringly absent holistic solution.
See how Spyderbat visualizes your environment by creating your free accout - sign up with Spyderbat today.
Want to see Spyderbat in action?
