With the rapid adoption of Kubernetes in organizations and the push to standardize the orchestration of resources with this approach, databases are now also being deployed into Kubernetes. Historically, persistent workloads like databases were not recommended for their deployment into Kuberntes as it was complex to manage how data would be stored. This was a result of Kubertnes originally being designed for non persistent microservice architectures.

In this blog post, I will be talking about audit and compliance and how to implement it with Calico. Most IT organizations are asked to meet some standard of compliance, whether internal or industry-specific. However organizations are not always provided with the guidance to implement it. Furthermore, when guidance has been provided, it is usually applicable to a more traditional and static environment and doesn’t address the dynamic nature of Kubernetes.

We are excited to introduce the early preview releases for Calico Enterprise 3.17. This release focuses on helping enterprises have a strong security posture for their containers and Kubernetes clusters. Let’s go through some of the highlights of this release.

DDoS or Distributed Denial of Service attacks have been around for a while and are notorious and painful to deal with (as with any other attack). As the name suggests, a DDoS attack causes an application or service to become unavailable to users due to resources exceeding it’s capacity and causing the app to either crash or become unresponsive. DDoS is a form of DoS where the attack comes from multiple sources (bots), usually spread across geographical locations.

Upwork is a freelancing platform that connects a global base of clients to freelancers via job postings. Since going public on the New York Stock Exchange in 2019, the company has become one of the leading freelance platforms worldwide and was named on Time’s list of the 100 Most Influential Companies of 2022.

In my previous blog on Kubernetes security foundations, we discussed the growing adoption of cloud-native applications and the security challenges they present. We highlighted the limitations of traditional network firewalls in securing these applications and emphasized the importance of implementing cloud-native security policies to protect network traffic effectively.

One of the common concerns about migrating applications to Kubernetes is the control over the network traffic egressing your environment. Due to its highly dynamic architecture, Kubernetes will not tie a specific IP address to an application by default. Instead, it will lease a different IP address from an IP pool whenever the application restarts.

Established in 1875, HanseMerkur is one of the oldest private health insurance companies in Germany, with customers across Europe. The company ran multi-tenant clusters on premises with Kubespray, with around 150 internal software developers as users. As the company must handle personal information and confidential data, it adheres to ISO 27001, the German equivalent of SOC 2, as per industry standards.

Kubernetes documentation clearly defines what use cases you can achieve using Kubernetes network policies and what you can’t. You are probably familiar with the scope of network policies and how to use them to secure your workload from undesirable connections. Although it is possible to cover the basics with Kubernetes native network policies, there is a list of use cases that you cannot implement by just using these policies.

The concern about securing the clusters has grown exponentially and one of the ways to secure it is by isolating the cluster from the Internet to lower the risk of eventual attack. Enterprises that deal with confidential customer data and work with regulatory agencies, such as financial and insurance institutions, require air gap environments for their clusters to create highly secure environments.