Open Source has proven instrumental in accelerating software development — providing developers with feature velocity, ease of customization, and quality reusable code. However, the open-source security landscape has clearly changed: it’s clear that the unwritten rule among the open-source community has expired, and open season on hacking open-source software projects has begun. Today’s threat actors have no qualms about injecting malicious code upstream as a way to target downstream applications. Developers need to recognize this new reality and rethink security across the software supply chain.
How did we get here? The push to accelerate digital transformation may be inadvertently introducing vulnerabilities into the software supply chain. Developers, under constant pressure to deliver new software to market faster, often rely on containerized open-source software and public repositories to meet dynamic, agile needs. According to Gartner, nearly three-quarters of global organizations will be running three or more containerized applications in their production environments by 2023. The Cloud Native Computing Foundation (CNCF) also confirmed a similar pattern in its survey, which found the use of containers in production has increased to 92 percent since 2019. With Kubernetes the dominant container orchestration solution, 32% of respondents in the CNCF survey indicated that security is one of their top three challenges in using containers.
Fixing this growing vulnerability will require both developers and operators to incorporate network security into the three phases of the software supply chain: In the build phase, they need to incorporate security into software development process, starting with the Kubernetes containers. In the run phase, developers need to harden the workloads that run on Kubernetes containers. And, finally, during the manage phase, operators need to secure network communications.
Build Phase: Secure Kubernetes Containers
The Kubernetes NetworkPolicy API allows developers to write policies that define internal connectivity and security requirements for their applications. These policies generally include the ability to:
- Block (and later, allow) incoming connections from pods, namespaces, or Classless Inter-Domain Routing (CIDR) blocks
- Block (and later, allow) outgoing connections to pods or namespaces
- Block (and later, allow) communications to specific ports
Network policies are applied by a Container Network Interface (CNI). This means that, regardless of how you access a pod, your CNI provider will still be able to block traffic because your CNI is acting directly on the machine that your pod is running on.
Run Phase: Harden Kubernetes Containers
Creating and applying the right policies and running end-to-end tests may not be enough. Before letting developers unleash the power of the Kubernetes API, you should understand the potential risks that may be introduced into the environment with each configuration attribute — and the Kubernetes mechanisms that help administrators control risk by setting security guardrails for their developers. These include container runtime, network exposure, role-based access control, volumes, the secret resource, custom resource definitions and other APIs.
PodSecurityPolicy can be used to define more secure defaults for new pods, such as preventing privilege escalation or turning off some default capabilities. When applying these kinds of rules, the PodSecurityPolicy doesn’t just validate, but actually mutates, the pod’s configuration. However, it does have its shortcomings. It only applies to pods, the scope is hard to define, pod rejection events may be hard to find or understand, there is no audit-only mode, and it’s not extensible. You can get around these issues by configuring the Kubernetes API service to send a webhook to each admission controller on incoming API calls. If all webhooks are returned, the API call will be executed; otherwise, it will be rejected.
A validating webhook admission controller configured to enforce workload security best practices, combined with a tight RBAC policy, are the best ways to minimize the security and operational risks introduced to a cluster via the Kubernetes API.
Manage Phase: Secure Network Communications
Modern cloud-native applications are dynamic, adaptive, and highly distributed, with hundreds of microservices deployed as containers supporting the demands of rapid feature releases, high resilience, and on-demand scalability. These containers are deployed on multiple nodes in a single Kubernetes cluster and quite often across multiple clusters and clouds. It’s important to manage and secure access to and from the application (north–south traffic) as well as to inspect communications between the microservices of the application itself (east–west traffic). North-south security includes managing and securing ingress access, implementing authentication and authorization, and configuring other ingress security features.
East-west security requires a separate service mesh that provides applications with features like service discovery, resilience, observability, and security without requiring developers to integrate or modify their code. Instead, all communication between services happens through a sidecar proxy that sits alongside each service. In Kubernetes, the injection of the sidebar alongside an application container is transparent to the user and happens automatically.
Level Up on Container Network Security
To summarize, modern applications and the need to speed development has made the software supply chain vulnerable to attackers. Containers are increasingly at risk of injection by highly-motivated, less-than-honorable threat actors who see open-source software and public repositories as fair game. In response, developers must improve the security of Kubernetes containers, harden Kubernetes workloads, and secure network communications across north-south and east-west traffic.
Learn how to step up your game and better secure your environments in this easy-to-read Container Network Security for Dummies guide. Download now.
