Posts under Kubernetes Security
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.
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.
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.
It’s a bit like Groundhog Day, where we just keep winning award after award. This time, StackRox takes the prize for Best DevOps/Container Security Solution in the inaugural Tech Ascension Awards. The judges celebrated the StackRox Kubernetes Security Platform as “the first deeply integrated, full life cycle solution for cloud-native applications that is both container-native and Kubernetes-native.” The team went on to cite that StackRox address all the critical security and compliance use cases for containers in a single platform, so customers can avoid buying multiple separate tools.
Google Cloud Platform (GCP) provides organizations with a scalable cloud infrastructure solution for building, deploying, and running cloud-native applications. StackRox is proud to announce that the StackRox Kubernetes Security Platform is available for all GCP customers on the GCP marketplace. Joint customers can now easily deploy StackRox from the GCP Marketplace to protect their Kubernetes environments running on GCP, Google Kubernetes Engine (GKE), Cloud Compute Engine (GCE), and Anthos.
StackRox has done it again. We’ve been recognized once more for our leadership role in the industry – this time as a finalist in the Black Unicorn Awards for 2019 at Black Hat, on now in Las Vegas. This award recognizes those cyber security innovators that judges deem have the potential to reach a $1 billion market potential. Cyber Defense Magazine chose just 30 finalists amongst all entries. Cyber security industry veterans Gary Miliefsky of Cyber Defense Magazine, Robert Herjavec of Herjavec Group, and David DeWalt of NightDragon served as the judges for this year’s Black Unicorn awards.
A new Kubernetes security vulnerability was announced today, along with patch releases for the issue for Kubernetes versions 1.13, 1.14, and 1.15. CVE-2019-11247 discloses a serious vulnerability in the K8s API that could allow users to read, modify or delete cluster-wide custom resources, even if they only have RBAC permissions for namespaced resources. If your clusters aren’t using Custom Resource Definitions (CRDs), you aren’t affected. But CRDs have become a critical component of many Kubernetes-native projects like Istio, so many users are impacted.