Automated namespace isolation with Calico

Calico has recently introduced a powerful new policy recommendation engine that enables DevOps, SREs, and Kubernetes operators to automatically generate Calico policies to implement namespace isolation and improve the security posture of their clusters.

This new recommendation engine is unique for three reasons:

1. Calico’s policy recommendations work continuously in the background over a user-configurable time period. This ensures that less frequent traffic flows are also accounted for in recommended policies.
2. Policy recommendations leverage Calico’s policy tiers. Tiers enforce an order of precedence on how Calico policies are evaluated and enforced. The recommended policies are placed in their own tier and Calico ensures each generated rule does not conflict with other policies you have implemented.
3. Recommended policies are StagedNetworkPolicies, allowing admins and operators to audit the behavior of these security policies before actively enforcing them.

In this blog, we’ll dive into each of these areas in more detail and provide an in-depth overview of how policy recommendations work and how it can improve the security posture of your cluster.

Before we get started, let’s quickly talk about namespace isolation and why it’s so important.

Why is namespace isolation important?

Namespaces are a foundational concept within Kubernetes. They help divide your Continue reading

Mitigating controls for cloud-native applications: Why you need them and how Calico Cloud can help

Fixing vulnerabilities can be hard—especially so for cloud-native applications. Let’s take a deeper look at why this is, and how mitigating controls can help secure your cloud-native applications.

Vulnerabilities are like earthquakes—its best to be prepared

The trials and tribulations of Log4j are now safely in our rearview mirror. Most of us responsible for operating a container platform like Kubernetes have navigated through the remediation efforts and disaster has been averted.

But it was a wake-up call for many, and at the very least a healthy reminder for all of us. There have been many infamous vulnerabilities before Log4j, and much like living in an area of the world where earthquakes can strike at any moment, much can be learned from the big ones that came before.

When Heartbleed was publicly disclosed in 2014 it sent shockwaves around the world. It was a critical vulnerability in the ubiquitous OpenSSL library—a cryptographic software library that is used to implement the Transport Layer Security (TLS) protocol. Most of the web relies on TLS to secure communication between clients and servers, and the vulnerability came about through a simple bug that resulted in improper input validation for heartbeats.

The bug existed in OpenSSL Continue reading

Do you really need a service mesh?

The challenges involved in deploying and managing microservices have led to the creation of the service mesh, a tool for adding observability, security, and traffic management capabilities at the application layer. While a service mesh is intended to help developers and SREs with a number of use cases related to service-to-service communication within Kubernetes clusters, a service mesh also adds operational complexity and introduces an additional control plane for security teams to manage.

What is a service mesh?

A service mesh is a software infrastructure layer for controlling and monitoring internal, service-to-service traffic in microservices applications.

Service mesh provides some of the middleware and some of the components that enable service-to-service communication, such as dynamic discovery. It provides capabilities around service discovery, load balancing traffic across services, security features around encryption and authentication, tracing observability, and more. The service mesh architecture leverages design patterns to enable communication between services without requiring microservices to rewrite applications.

Service mesh architecture

One of the key aspects of how a service mesh works is that it leverages a sidecar design pattern. Services communicate and handle requests via a proxy, which is dynamically injected into each pod. Envoy is one of the most popular proxies Continue reading