A potentially serious and unpatched security issue was opened over the weekend in the Kubernetes GitHub repository: the parsing of YAML manifests by the Kubernetes API server could lead to a denial-of-service attack against a cluster’s Kubernetes API service, therefore leaving it vulnerable to an instance of a “billion laughs” attack. While a CVE candidate has been reserved, with full details for the CVE yet to be published, it still presents a substantial threat to Kubernetes cluster security that you can and should take steps to protect against.
By now most of us have heard about the role human error plays in causing data breaches. TheCapital One breach from July is just the latest in a long line of security incidents that can trace their success back to a misconfigured infrastructure or security setting. As organizations accelerate their use of containers and Kubernetes and move their application development and deployment to cloud platforms, preventing avoidable misconfigurations in their environment becomes increasingly crucial.
As the container ecosystem has matured, Kubernetes has emerged as the de facto orchestrator for running applications. The advent of declarative and immutable workloads has paved the way for an entirely new operational model for detection and response. The rich set of workload metadata augments and elevates traditional detection approaches. One such detection approach is anomaly detection. Anomaly detection consists of first creating an activity baseline for an application and then measuring future events against that baseline.
This week marked the release of Kubernetes 1.16 and, like previous releases, delivers a range of exciting new features and enhancements that showcase its rapid velocity and maturity, driven by a community of more than 32,000 individual contributors. At StackRox, we have always viewed one of the greatest advantages of Kubernetes’ design to be its inherent extensibility and scalability, which continues to be evidenced by several updates in this latest version.
The Kubernetes project released patches yesterday for kubectl 1.13, 1.14, and 1.15, and also released kubectl 1.16.0 along with the release of Kubernetes 1.16. The previous versions were patched to address ongoing security vulnerabilities with the kubectl cp subcommand that could allow critical files to be overwritten or exfiltrated by accidental or malicious replacements when copying from a running container. Fixing CVE-2019-11251 To address CVE-2019-11251, update all installations of the kubectl program to 1.
Containers, along with orchestrators such as Kubernetes, have ushered in a new era of application development methodology, enabling microservices architectures as well as continuous development and delivery. Docker is by far the most dominant container runtime engine, with a 91% penetration according to our latest State of the Container and Kubernetes Security Report. Containerization has many benefits and as a result has seen wide adoption. According to Gartner, by 2020, more than 50% of global organizations will be running containerized applications in production.
Following security best practices for AWS EKS clusters is just as critical as for any Kubernetes cluster. In a talk I gave at the Bay Area AWS Community Day, I shared lessons learned and best practices for engineers running workloads on EKS clusters. This overview recaps my talk and includes links to instructions and further reading. About EKS Amazon Elastic Kubernetes Service (EKS) is AWS’ managed Kubernetes service. AWS hosts and manages the Kubernetes masters, and the user is responsible for creating the worker nodes, which run on EC2 instances.
Operationalizing container security by integrating with existing DevOps tooling and workflows has long been a design principle in how we’ve built our StackRox Kubernetes Security Platform. Today we’re excited to announce yet another powerful integration to make our customers’ operational lives better – the StackRox App for Sumo Logic. With this integration, joint customers now get rich StackRox insights about Kubernetes and container security incidents directly in the Sumo Logic Continuous Intelligence Platform.
If you run workloads in Kubernetes, you know how much important data is accessible through the Kubernetes API—from details of deployments to persistent storage configurations to secrets. The Kubernetes community has delivered a number of impactful security features over the years, including Role-Based Access Control (RBAC) for the Kubernetes API. RBAC is a key security feature that protects your cluster by allowing you to control who can access specific API resources.
The Kubernetes project recently completed a security audit, including a review of source code, system design, and live behavior in a test environment. The Security Audit Working Group released the results publicly, including: A final report detailing the audit process, describing the issues uncovered, and recommending technical or design changes to Kubernetes developers, and A threat model describing key Kubernetes components and how effectively they implement important security controls The Working Group also released materials to help cluster administrators, operators, or developers apply better security practices to their Kubernetes clusters and applications:
Here at StackRox, we continue to deliver product innovations that help our customers more effectively protect their cloud-native environments. Our platform’s Kubernetes-native approach ensures that security is built into infrastructure, not bolted on, while integrating seamlessly with existing DevOps workflows and toolchains. The end result: better scalability, greater consistency, and less operational risk for your applications and infrastructure. Today we’re taking a moment to detail a range of new features in the latest release, version 2.