Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

The fourth annual Sysdig container security and usage report looks at how global Sysdig customers of all sizes and industries are using and securing container environments. By examining how and when organizations are implementing security in the development lifecycle, we have been able to uncover some interesting data points in this year’s report. For example, we can see that 74% of organizations are scanning container images in the build process.

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.