Posts under Kubernetes Security
Being based in one of the more impacted COVID-19 areas in the U.S. - Silicon Valley - we at StackRox, like many other companies, are entering our third week with employees working from home. Many members of our team are supporting at-home learning for their children as well. Family and health come first – always. We are committed to offering our employees the flexibility and understanding that they need to take care of their families – without any additional stress or worry.
I’ve always said the best part of my job is talking to customers – especially happy customers! – and I got that chance a couple weeks ago in interviewing George Gerchow, the chief security officer at Sumo Logic. George is one of those “no BS, move fast, lead by serving, and do it all with a smile” guys. And he’s unflinching about the criticality of security to the company he serves.
Today we’re excited to take another step in our partnership with AWS – earning Container Competency partner status. This certification provides our joint customers with the peace of mind to know that the StackRox Kubernetes Security Platform integrates easily with both Amazon EC2 (Elastic Compute Cloud) and Amazon EKS (Elastic Kubernetes Service). Complementing AWS with StackRox security for containers and Kubernetes fulfills a key piece of the shared responsibility model. While Amazon takes responsibility for managing and securing the underlying infrastructure in both its IaaS (EC2) and PaaS (EKS) offerings, customers retain responsibility for securing their application workload.
Today we shared the news that StackRox supports the Anthos platform (download joint solution brief), extending the reach of our hybrid and multicloud security approach. Anthos and the StackRox Kubernetes Security Platform share a lot of common principles in delivering consistency across different environments – enabling both the infrastructure itself as well as the security policies and controls to bridge these worlds makes for a powerful combination. Hybrid and multicloud adoption are on the rise, as demonstrated in StackRox research and other reports.
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.
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.
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.
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.
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.
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: