Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

Today, Red Hat announced its intent to acquire Stackrox. This is a very exciting development in the world of cloud-native security! First and foremost, congratulations to Stackrox, an early participant in the container security space. This acquisition is a great outcome for Stackrox given their nascent scale and on-premises offering.

Most modern organizations understand that the earlier you integrate security into the development process, the more secure the applications will be in production. For containerized workloads, securing the container image throughout the application life cycle is a critical part of security, but many organizations don’t even follow basic best practices for ensuring secure container images.

Kubernetes continues to be a popular platform for deploying containerized applications, but securing Kubernetes environments as you scale up is challenging. Each new container increases your application’s attack surface, or the number of potential entry points for unauthorized access. Without complete visibility into every managed container and application request, you can easily overlook gaps in your application’s security as well as malicious activity.

CVE-2020-8554 is a vulnerability that particularly affects multi-tenant Kubernetes clusters. If a potential attacker can create or edit services and pods, then they may be able to intercept traffic from other pods or nodes in the cluster. An attacker that is able to create a ClusterIP service and set the spec.externalIPs field can intercept traffic to that IP. In addition, an attacker that can patch the status of a LoadBalancer service can set the status.loadBalancer.ingress.ip to similar effect.

A few weeks ago a solution engineer discovered a critical flaw in Kubernetes architecture and design, and announced that a “security issue was discovered with Kubernetes affecting multi-tenant clusters. If a potential attacker can already create or edit services and pods, then they may be able to intercept traffic from other pods (or nodes) in the cluster.” If a hostile user can create a ClusterIP service and set the spec.externalIP field, they can intercept traffic to that IP.

In part 1 of this blog series on data protection for Kubernetes and cloud native applications, we addressed the need for Data Protection for Containerized Applications. Given that the leading Kubernetes distributions and managed cloud services do not include native capabilities for data protection and disaster recovery, service providers and enterprises need additional data management tools such as CloudCasa to provide these.

If you have used Open Policy Agent (OPA), you must have used OPA Playground to write and test out your Rego policies. I always wished for a feature where the policies in the playground can be directly applied in OPA. Basically, a control plane which allows policy authoring and enforcement easily. In KubeCon NA 2020, Styra (creators of OPA) launched a free edition of their Declarative Authorisation Service (DAS).

Whether you’re a developer or an IT professional (or a bit of both!), enforcing and managing authorization policies for the new containerized world is a whole different ball game than it was before. There’s the complex nature of modern applications — composed of multiple microservices, housed in containers — and then there’s the dynamic nature of platforms like Kubernetes, running those applications.