Posts under Kubernetes Security
When you’re managing the distribution of people’s paychecks, you’ve got a high bar to meet on security. So for Namely, whose SaaS application supports payroll, people management, compliance and tax, and team collaboration for hundreds of thousands of users, security has been a priority from Day 1. The move to a microservices architecture, however, drove the need for a whole new approach to security. Namely’s flagship SaaS platform uses hundreds of services that are constantly being released and updated, so the company standardized on Kubernetes to scale and operationalize infrastructure management.
A vulnerability that might enable a man-in-the-middle attack on Kubernetes clusters, CVE-2020-10749, was disclosed a few days ago. This vulnerability is not in Kubernetes itself but rather in certain container networking implementations – IPv4-only clusters using affected implementations are vulnerable. The vulnerability allows for man-in-the-middle (MITM) attacks, where an attacker can intercept network traffic to a pod in a Kubernetes cluster and impersonate it to clients. How It Works To understand this vulnerability, here’s some relevant background:
By every measure, Kubernetes is dominating the container orchestration market. Our latest State of Kubernetes and Container Security report found that 87 percent of organizations are managing some portion of their container workloads using Kubernetes. The same survey shows that 94 percent of organizations have experienced a serious security issue in the last 12 months in their container environment, with 69 percent having detected misconfigurations, 27 percent experiencing runtime security incidents, and 24 percent discovering significant vulnerabilities to remediate.
In Part 1 of this series on the Open Policy Agent (OPA), we gave a brief rundown of why you might want to use the OPA Gatekeeper controller for policy enforcement in your Kubernetes clusters. We also gave a few examples of OPA’s query language, Rego, and of the Kubernetes Custom Resource Definitions (CRDs) that OPA Gatekeeper uses and creates. This follow-up post dives into practical aspects of writing and implementing OPA policies for Kubernetes clusters, demonstrating a working example that can be used to restrict a pod’s allowed tolerations of node taints.
It’s always a great feeling to learn another customer win story, but it’s especially exciting when you’re a customer in return! That’s the fun I had talking with Greenlight to learn how the company relies on StackRox to protect its Kubernetes applications. Greenlight has a cool mission: teach kids about financial literacy, encouraging them to create a budget and helping them reach savings goals. I grew up with a mother who gave me envelopes with my first allowance, and I had to distribute my four pennies across each one (labeled spend, save, gifts, and charity, in case you were wondering).
Last week we published part one of our five-part Amazon’s Elastic Kubernetes Service (EKS) security blog series discussing how to securely design your EKS clusters. This blog post expands on the EKS cluster security discussion and identifies security best practices for your critical cluster add-ons. EKS leaves the task of installing and managing most AWS service integrations and common Kubernetes extensions to the user. These optional features–often called add-ons–require heightened privileges or present other challenges addressed below.
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.
When it comes to cloud services like AWS, customers need to understand what features and tools their cloud provider makes available, as well as which pieces of the management role falls on the user. That share of the workload becomes even more critical with respect to securing the Kubernetes cluster, the workloads deployed to it, and its underlying infrastructure. Customers share the responsibility for the security and compliance of their use of services with AWS.
Welcome to the final post in our four-part series on security best practices for Azure Kubernetes Service. In the first three installments, we covered how to create secure AKS clusters and container images (part 1), how to lock down cluster networking (part 2), and how to plan and enforce application runtime safeguards (part 3). This post will close out the series by covering the routine maintenance and operational tasks required to keep your AKS clusters and infrastructure secured.
We recently asked IT and security professionals working at organizations that have adopted containers to rate the importance of several container security capabilities and use cases for their environments. We found that respondents put a premium on addressing those security use cases that allow them to shift security left and apply best practices earlier in the container life cycle, with vulnerability management and configuration management taking two of the top three spots.
Today, StackRox published its State of Kubernetes and Container Security Report, Winter 2020 edition (download your full copy here) - a first of its kind. Based on responses from more than 540 Kubernetes and container users across IT security, DevOps, engineering, and product roles, the report provides insights into how organizations are adopting containers and Kubernetes and its security impact. Of all the survey responses, five findings stand out as the biggest surprises.
Azure Kubernetes (AKS) Security Best Practices Part 1 of 4: Designing Secure Clusters and Container Images
Microsoft’s Azure Kubernetes Service (AKS), launched in June 2018, has become one of the most popular managed Kubernetes services. Like any infrastructure platform or Kubernetes service, though, the Azure customer has to make important decisions and formulate a plan for creating and maintaining secure AKS clusters. While many of these requirements and responsibilities apply to all Kubernetes clusters, regardless of where they are hosted, AKS also has some specific requirements that the platform users must consider and act on to ensure that their AKS clusters and the workloads their organization runs on them will be safeguarded from possible breaches or other malicious attacks.
As 2018 was coming to a close, and the blistering pace of Kubernetes adoption showed no signs of slowing, the first major Kubernetes security vulnerability was discovered in the container orchestrator (CVE-2018-1002105), with a criticality score of 9.8. The vulnerability enabled attackers to compromise clusters via the Kubernetes API server. Increasing the impact, this vulnerability had existed in every version of Kubernetes since v1.0 – so everyone using Kubernetes at that point was potentially affected.
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.