In surveys conducted at last year’s KubeCon + CloudNativeCon in October, two-thirds of organizations confirmed they plan to run more than half of their production applications on a Kubernetes-enabled, cloud-native microservice architecture within the next two years. As organizations continue to see the competitive advantages in pace and capabilities that technologies such as Kubernetes (K8s) provide, the pressure to adapt and adopt only increases. While most are willing and able to make the cultural shift to iterative methodologies such as DevOps and Agile, running K8s environments securely and cost-effectively at scale remains an elusive goal in most operations.
Technical Challenges in Kubernetes Adoption
While some cloud platform vendors have begun to address cost management K8s issues with new developer-ready infrastructure services that adapt automatically to evolving requirements, K8s security remains an ad hoc assembly that even K8s documentation calls “suggestions.” Among adopters, 93% report having experienced a majority of K8s security incidents in the last twelve months, with 31% of incidents resulting in revenue or customer loss.
For security and development teams, the principal technical challenge to K8s security is twofold:
- Flat Networking: K8s relies on a lateral networking model that allows each pod in a cluster to communicate with any other. Thus, if attackers compromise one pod, all other resources in the cluster are at risk.
- Configurability: To accommodate the widest range of configurations, K8s is minimally configured out-of-the-box, leaving users responsible for secure, custom configurations.
4Cs Kubernetes Security Model
The current standard for Kubernetes security is a defense-in-depth approach common to all varieties of risk mitigation in engineering. In hazard analysis, when design and planning can’t sufficiently protect against a single-point catastrophic failure, the most efficient way to harden the system against risk is to add layers of redundancy. In K8s, developers overlay security in four stages:
- Code: Consists of regular vulnerability scans and static code analyses
- Container: Requires image scanning and validation along with disabling privilege escalation
- Cluster: Involves role-based access control (RBAC) and application secret encryption
- Cloud: Highly depends on the recommended best practices of the service provider
What the four Cs of K8s security practices have in common is preemption, through scanning, configuration, or policy. Nevertheless, each case involves reliance on one or more uncontrollable variables. Third-party service providers offer limited network visibility. Scanning and static analysis provide no runtime security against new upstream dependency vulnerabilities.
Attacks on container-based infrastructure have been on the rise since early 2020 and most public containers carry more vulnerabilities in 2022 than in 2021. These trends – combined with the initial technical hurdles of K8s adoption – suggest that additional layers of preemptive security will only fall off in effectiveness parabolically over time as new vulnerabilities and possible misconfigurations outpace detection capabilities.
Runtime Kubernetes Security with Spyderbat
Spyderbat’s cloud-native runtime security platform creates unprecedented runtime visibility and attack prevention for K8s and containers. With eBPF-enabled system and container-level insight for live and historic activities across your runtime environments, your teams intercept threat actor exploits just right of boom for early detection and thorough removal. Additionally Spyderbat’s level of insight enables the automatic creation of guardrails, continuously comparing running applications to prior versions to detect application drift with the insights needed to immediately get your application back on track.
To schedule a live demo, contact Spyderbat here.
Write a comment