When you’re focused on revolutionizing the Accounts Receivable (AR) market, feature innovation and delivery are your lifeblood, and containers and Kubernetes become your currency. Protecting customer data on that cloud-native infrastructure is essential to successfully disrupting this FinTech market. YayPay is proud of its digital disruptor status, and StackRox is proud to have enabled the security and data protection YayPay needs to fuel customer growth. It’s always fun to work with “born in the cloud” companies like YayPay.
I recently joined Mitch Ashley from DevOps Chat to dive into the need for a systemic security approach across the life cycle of cloud-native, Kubernetes applications. We explored how Kubernetes and cloud-native apps bring access to rich configuration information, usage visibility, runtime context, inherent security controls and compliance. You can listen to our conversation by clicking below, or you can read through the transcript of our talk that follows.
Below is the transcript of the video, condensed and modified for clarity. Some of us are pushing Kubernetes at our organizations and some of us are getting Kubernetes pushed on us at our organizations. This marks a huge paradigm shift in infrastructure, the way that we manage software and applications, and the way that developers deploy their applications. When you think about DevOps, it’s every SREs dream to have developers manage their own applications but that means that they’re pushing code to production and we’re building pipelines for people to quickly develop and push code, and from a security standpoint, that makes me a little scared.
Right on the heels of our recent news announcing new security controls, today we at StackRox unveiled the latest update to the StackRox Kubernetes Security Platform. In this release, we’re supporting additional container operating systems and image registries, simplifying deployment with availability on cloud marketplaces, adding native integrations with SIEM and incident management platforms, and supporting the Istio service mesh. As with so many of our innovations, StackRox customers spurred many of these capabilities.
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.