Posts under kubernetes security
KubeCon Announcement and Linux Foundation Update On Tuesday during KubeCon, the Cloud Native Computing Foundation (CNCF) announced the Certified Kubernetes Security Specialist certification is now generally available. The announcement confirmed important information that we previously outlined in our most recent blog detailing the CKS. Thanks to the updates from the Linux Foundation documentation, the updated exam structure is: 2 hours long Require a passing score of 67% 15-20 performance-based tasks Uses Kubernetes version 1.
This is part three of our four-part OpenShift security blog series. Don’t forget to check out our previous blog posts in the series: Part 1 - OpenShift security best practices for designing clusters Part 2 - OpenShift networking and cluster access best practices Adhering to best practices for running your workloads in OpenShift is critical to keeping the cluster and all its workloads safe. While Kubernetes provides several capabilities that can help protect your workloads, it’s up to you to use them to safeguard your cloud-native applications.
What is the Certified Kubernetes Security Specialist (CKS)? The CKS is the third Kubernetes based certification backed by the Cloud Native Computing Foundation (CNCF). CKS will join the existing Certified Kubernetes Administrator (CKA) and Certified Kubernetes Application Developer (CKAD) programs. All three certifications are online, proctored, performance-based exams that will require solving multiple Kubernetes security tasks from the command line. With the massive investment into Kubernetes over the last five years, these certifications continue to be highly sought after by many seeking technical knowledge about Kubernetes.
Red Hat’s OpenShift Container Platform (OCP) is a Kubernetes platform for operationalizing container workloads remotely or as a hosted service. OpenShift enables consistent security, built-in monitoring, centralized policy management, and compatibility with Kubernetes workloads. The rapid adoption of open source projects can introduce vulnerabilities in standard Kubernetes Environments. OCP supports these projects internally, allowing users to gain open source advantages with a managed product’s stability and security. OpenShift offerings include five managed and two hosted options.
Organizations are rapidly moving their Kubernetes applications to production to accelerate feature velocity and drive digital transformation and business growth. Our latest State of Kubernetes Security survey report shows that companies have standardized on Kubernetes, and this rapid adoption offers equal parts promise and peril. Promise, in the form of infrastructure that enables far greater inherent security than ever before. And peril, as companies struggle to overcome a skills gap and configure the technology in the most secure manner.
Faster application development and release, quicker bug fixes, and increased feature velocity are three of the most often cited benefits of containerization. However, when security becomes an afterthought, you risk diminishing the greatest gain of containerization – agility. Rolling out an application that hasn’t passed a security assessment puts the business at too great a risk. To prevent delays in application deployment and realize the benefits of containers and Kubernetes, organizations must shift left with security, building it into the development phase so they can address as many security challenges as possible during the build stage.
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.