We’re excited to announce today that we’ve added support for the latest version of the Google Cloud Security Command Center (Cloud SCC). StackRox has collaborated with the Cloud SCC team as part of our Google Cloud partnership since Cloud SCC’s alpha release, and we’re excited that the platform is now generally available. The StackRox Kubernetes Security Platform enables customers to meet their security and compliance requirements across the container lifecycle, and we’ve integrated deeply with Kubernetes to deliver the key capabilities essential to an effective container security solution.
Here at Stratus Medicine, we have the challenge of figuring out how to secure code that we didn’t write. Think of us as the middleman between healthcare providers wanting to test innovative applications and healthcare application creators looking to get their new software running with real users and real data sets. Our Stratus Platform brings these groups together, which leaves us with the task of securing sensitive patient data along with code we didn’t write.
The container orchestrator war is over, and Kubernetes has won. With companies large and small rapidly adopting the platform, security has emerged as an important concern – partly because of the learning curve inherent in understanding any new infrastructure, and partly because of recently announced vulnerabilities. Kubernetes brings another security dynamic to the table – its defaults are geared towards making it easy for users to get up and running quickly, as well as being backward compatible with earlier releases of Kubernetes that lacked important security features.
Two Kubernetes security vulnerabilities were disclosed yesterday: CVE-2019-1002101, a high severity issue, and CVE-2019-9946, a medium severity issue. Read on for a description of the vulnerabilities and their impact, how to know whether you’re affected, and what the remediation steps are. CVE-2019-1002101: kubectl cp could replace or delete files on a user machine This vulnerability is in the kubectl binary – specifically, in the kubectl cp command. An attacker can exploit this vulnerability to write files to any path on the user’s machine, limited only by the system permissions of the local user.
Kubernetes 1.14 is out! As always, we at StackRox are excited to dive in and see what’s new. And this release didn’t disappoint – from major new features and security improvements to small enhancements that simplify the day-to-day life of operators, this update includes a lot to unpack (and a few deprecation warnings to watch out for!). Windows Support is now Stable This feature is the big one: starting with 1.
Earlier today, the CyberEdge Group published its 6th annual Cyberthreat Defense Report. The report includes a variety of interesting findings, which we’ll detail below. But the section of the report I found most interesting comes after all the survey results. “The Road Ahead” chapter offers advice on areas of security that need “proactive attention and investment.” The authors took great time and care to lay out the advanced capabilities needed to secure containers, citing:
Kubernetes provides several built-in security capabilities, including network security, resource isolation, access control, and logging and auditing. One of the more recent security capabilities is a group of plugins known as admission controllers. Admission controllers enable governance and enforcement of how clusters are used. Kubernetes ships with over 30 admission controllers, which are listed here along with their descriptions. This article assumes you have a basic understanding of admission controllers, but if you are unfamiliar with them, check out Kubernetes reference guide on admission controllers to learn more.
Like the “participation” trophy every kid on the soccer team wins in kindergarten, some industry awards just don’t carry much clout. The SC Magazine awards? Now that’s a different story. These awards, announced in conjunction with the RSA Conference every year, bestow a huge amount of prestige on the companies and technologies they celebrate. The award submissions are incredibly competitive, and I know of many companies who try year after year to win and fall short.
This morning, a new security issue that affects nearly every version of Kubernetes was disclosed by the Kubernetes Product Security Team (CVE-2019-1002100). It is medium severity, and Kubernetes administrators are advised to first check and limit role-based permissions on Kubernetes users. Container infrastructure maintainers should subsequently consider upgrading the Kubernetes API server to a recently patched version. Vulnerability Summary CVE-2019-1002100 is a denial of service (DoS) vulnerability that exists in the Kubernetes API server, allowing users with certain write permissions on the Kubernetes API to make write requests that cause the API server to utilize excessive resources.
Today we introduced a slew of new compliance capabilities, including support for NIST, PCI, and HIPAA. As we’ve talked with customers about the functionality they need, a few key trends have emerged that informed how we designed our StackRox Kubernetes Security Platform to support compliance. We love how one customer reacted to our new features: StackRox gives us the ability to demonstrate our adherence to HIPAA at all times, helping us avoid audit-induced anxieties.
A vulnerability in runC, which allows an attacker to gain host-level code execution by breaking out of a running container, was discovered and reported by Adam Iwaniuk and Borys Poplawski in early January and published as CVE-2019-5736 on 11 February 2019. This vulnerability is highly significant in that it: enables container isolation breakout with minimal interaction from an authorized host user; typically allows an attacker to obtain root privileges on the host; negatively impacts most container environments because many containers run with default Docker security settings and default user (UID 0); and affects runC, the most commonly used low-level container runtime in Docker and Kubernetes environments.