In my previous blog post, What you can’t do with Kubernetes network policies (unless you use Calico): Advanced policy querying & reachability tooling, I talked about this use case from the list of nine things you cannot implement using basic Kubernetes network policy — advanced policy querying and reachability tooling. In this blog post, we’ll focus on the use case — the ability to log and analyze network security events.

In the ever-evolving landscape of Kubernetes networking and security, Calico has proven to be a battle-hardened, scalable and robust solution. Core to Calico’s architecture are two components, Felix and Typha. And given their importance for running Kubernetes deployment, it is no surprise that monitoring these components is crucial to secure and maintain them for optimal cluster operation.

NXDOMAIN, indicating the non-existence of a queried domain, poses significant challenges within Kubernetes, impacting application functionality, service communication, and overall cluster stability. Investigating NXDOMAIN responses in Kubernetes is vital for sustaining the reliability, performance, and security in a containerized environment.

Many organizations have adopted IP address allowlisting for their corporate cloud applications as an added layer of security. Many sanctioned cloud applications and web services enforce access restrictions based on the source IP address of incoming traffic. To establish a connection with these remote SaaS services, your traffic must originate from a particular IP address that is pre-registered. Any traffic originating from different IP addresses will be denied access by these remote applications.

As you are using OpenShift or are planning to use it for your containerized applications, ensuring robust security is crucial. As you dive deeper and your workloads become more complex, the need for advanced security measures becomes apparent. This is where Calico’s microsegmentation capability helps to achieve tenant and workload isolation. Let’s explore how Calico can be a game-changer in strengthening the security posture of your OpenShift environment.

As 2023 comes to a close, we’re happy to report that we’ve had a successful year full of powerful product advancements and notable third-party recognition.

Based on the well-known cybersecurity method, “honeypots”, Calico Cloud runtime security approach of Honeypods as decoy pods are designed to attract traffic to them from malicious sources and to detect suspicious activity within a Kubernetes cluster.

This week’s news of Cisco’s intent to acquire Isovalent sends an important message to the cloud security ecosystem: network security is no longer an afterthought in the cloud-native world. It’s now a critical component of any robust security posture for cloud-native applications. This move not only validates the work of the Isovalent team in evangelizing this essential category but also underscores the vision Tigera has pioneered since 2016 with Project Calico.

The surge of cloud-native applications has propelled Kubernetes into the forefront, revolutionizing how we manage and deploy workloads. However, this exponential growth has also increased the security challenges, and attack surface, DevOps and Security teams must address. As we discussed in a previous blog post, traditional network security measures fall short when presented with Kubernetes’ dynamic nature, demanding a paradigm shift towards more adaptable solutions.

In my previous blog post, What you can’t do with Kubernetes network policies (unless you use Calico): Policies to all namespaces or pods, I talked about this use case from the list of nine things you cannot implement using basic Kubernetes network policy — policies to all namespaces or pods. In this blog post, we’ll be focusing on the next use case — advanced policy querying and reachability tooling.