Posts under Kubernetes Security
To understand how to effectively secure your Kubernetes environments, it is informative to understand the architecture of Kubernetes itself as well as where and how to focus efforts on valuable mitigations, especially those which require administrator or user configuration when provisioning clusters. Kubernetes is a robust yet complex infrastructure system for container orchestration, with multiple components that must be adequately protected. Each Kubernetes cluster consists of two sets of components: (1) the control plane which is used to manage operations throughout the cluster, and (2) the cluster’s worker nodes which run containerized applications in pods.
We were already having a great day yesterday – responding to all the congratulations messages on our funding, our huge 240% increase in revenue, and our customer momentum – when news hit that we were named amongst that select group of SINET 16 Innovator Award winners. Wow. The tally of security vendors hovers around 2500, and we’re called out as one of the 16 most innovative across that entire landscape. This recognition is just one more indicator of the power of our unique approach to securing cloud-native infrastructure.
I’ve had the good fortune to get to know Pathik Patel, head of cloud security at Informatica, over the past 18 months since he became a StackRox customer, and today we’re sharing the news of our joint success story. Across our numerous conversations, he has repeatedly impressed me with his forward thinking on how to innovate security processes, approaches, and tooling to keep Informatica at the forefront of securely enabling sophisticated data management, detailed in this case study.
Right on the heels of last week’s news that we’re providing Kubernetes security for DoD’s Platform One software factory, we’re excited to share today that we’ve been awarded a Phase III contract with the Department of Homeland Security. In this stage of our partnership, we’re deploying our Kubernetes Security Platform to protect running systems at a large U.S. bank. The DHS Science and Technology Directorate (S&T) uses its Silicon Valley Innovation Program (SVIP) to invest in next-generation security technologies to protect critical infrastructure, including mission-critical, cloud-native applications for financial institutions.
Part six of our nine-part blog series – where we examine each of the nine MITRE ATT&CK tactics and techniques for Kubernetes – covers Credential Access, a set of activities intended for stealing sensitive credentials such as application secrets, passwords, and tokens that may be used by either users or service accounts. These credentials can subsequently be used to gain access to resources that include applications, cluster resources (e.g., pods, controllers, or other Kubernetes objects), cloud resources, and others.
StackRox is in the midst of our own “Fed ramp” of sorts, with news today that we’ve been awarded a Department of Defense SBIR Phase II Award, our long history with In-Q-Tel and multiple deployments in the U.S. Intelligence Community, and more news coming soon on additional Fed initiatives. We have deep roots in protecting the cloud-native apps of many civilian and Intelligence Community agencies, including our long partnership with In-Q-Tel.
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.