StackRox has pioneered Kubernetes-native container security, bringing rich context and infrastructure-native enforcement to protecting Kubernetes and containers across build, deploy, and runtime. We recognize the importance of getting critical alerts about this cloud-native stack to the right team, at the right moment – by integrating with PagerDuty, we broadened the choices on how to do so. To effectively protect the cloud-native stack, DevOps and security teams must be able to operationalize the security technologies designed to protect this new infrastructure.
Just in time for KubeCon next week, we’re announcing today the 3.0 version of our StackRox Kubernetes Security Platform. We’re really proud of the industry-first capabilities we’re introducing with this upgrade, enabling our customers to better harden their Kubernetes and container environments. Every time we build new functionality into our platform, we keep a relentless focus on the staff responsible for operationalizing container and Kubernetes security. This lens informs everything about how we design new capabilities.
SOC (System and Organization Controls) 2 is a set of compliance requirements that applies to companies that store, process, or transmit customer data. A broad range of companies, including SaaS providers, may need to comply with SOC 2 to be competitive in the market and keep customer data secure. Public cloud providers such as Amazon Web Services, Google Cloud Platform, and Microsoft Azure are subject to SOC 2 and make their audit reports publicly available.
I recently joined Alan Shimel, editor-in-chief of DevOps.com for a chat about what it means to be a Kubernetes-native security platform and why we believe it’s the most effective way to secure containers and Kubernetes. You can watch our conversation in the video below, or you can read through the transcript of our talk that follows, condensed and modified for clarity.
The Kubernetes team has released patches for the recently disclosed “Billion Laughs” vulnerability, that allowed an attacker to perform a Denial-of-Service (DoS) attack on the Kubernetes API server by uploading a maliciously crafted YAML file. With those patches comes the disclosure that the vulnerability was more severe than previously announced, as it could even be triggered by unauthenticated users (in Kubernetes 1.13) or any authenticated user, even when only granted read access via RBAC (Kubernetes 1.
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.