Secure

Zero Trust is an architecture model that no longer bases the security of an IT system solely on the defense of its perimeter but on the total absence of trust between parties. It's a highly secure and difficult model to implement, in which every connection must be authorized.

The basic principle of Zero Trust architecture is to trust no one or no device by default, even if they're inside the network, and to constantly check the identity and permissions of everything that attempts to access corporate resources. No implicit trust is placed in a user or service based on where the request originates. 

Zero trust doesn't mean you should stop restricting access to resources via network filtering! The Zero Trust model assumes that the network will necessarily be compromised and the perimeter will fail, forcing users and devices to prove their legitimacy.

Zero Trust is particularly well-suited to Cloud infrastructures, which often have a complex network typology comprised of several interconnected virtual networks exposed on the Internet, where the very notion of the perimeter has endless meaning, especially in serverless infrastructures...

This approach is attractive but complex to implement. Each user and application must use a centralized authentication system (e.g., MFA for users, SSL certificates for servers). Typically, an identity broker links external terminals (user workstations) and services hosted on the infrastructure (e.g., Boundary). Services such as CloudFlare Zerotrust greatly simplify the implementation of this type of architecture.

Buildkit is a container image build engine that works with low privileges while fully covering the possible instructions for a Dockerfile.

Today, building container images is a central CI/CD issue for containerized applications. But it's also often a costly operation involving compiling binaries, and thus a heavy RAM and CPU load.

So, in order to adapt to a heavy but highly variable load depending on the developments in progress, it's comfortable to carry out these builds in Kubernetes clusters, often shared with other tools.

To ensure the security of these clusters, it is essential that the tools they host, and therefore in particular container image build tools, are run without privileges.

Historically, container image builds have required a privileged process. As a result, a developer with the right to launch a build pipeline could take control of all containers running on the same node. 

Fortunately, a number of Linux kernel upgrades over the last few years have made it possible to launch containers with virtually no privileges. And build engines have adapted accordingly. Tools such as Buildkit, Buildah, and Kaniko all consider these new possibilities in their own way.

Among these tools, we currently favor Buildkit for our projects, as it seems to be the only one among them to really manage all the possible instructions of a Dockerfile. What's more, it's built on a client-server model, which means we can take advantage of a common cache and deliver excellent performance, thus reducing the time needed to build. 

A security feature that speeds up development - it's possible!

Cilium is an extremely powerful open-source network plugin for Kubernetes that offers advanced security and observability features with ease of access. It is currently considered the market benchmark in its field.

Cilium is an open-source network NIC project for Kubernetes, which evolved from CNCF in October 2022. It offers advanced features such as transparent traffic encryption between pods, advanced network filtering, enhanced traffic observability, and multi-cluster communication.

Cilium's great strength is that this CNI is based on eBPF (Extended Berkeley Packet Filter). eBPF is a Linux kernel technology that can run isolated programs in kernel space. It is used to safely and efficiently extend kernel capabilities without modifying the kernel source code or loading additional kernel modules.

This results in several benefits: performance is significantly higher than with iptables used by kube-proxy. Thanks to ePBF, Cilium does not require any kernel module to be installed so that it can run without any prerequisites on any server with a sufficiently recent Linux kernel (kernel 4.19). 

Cilium offers many essential features when your Kubernetes cluster becomes your infrastructure's central and critical point, particularly in terms of security and observability. For example, it's possible to perform Layer 7 network filtering with CiliumNetworkPolicy CRD or gain in-depth visibility into Layer 7 traffic using metrics exposed by Cilium.

Cilium also makes it easy to encrypt traffic between pods. For those who use a Service Mesh solely for mTLS encryption, Cilium offers a simpler solution. 

Falco is an intrusion detection tool for Kubernetes. It relies on dynamic container analysis to raise security alerts in the event of suspicious behavior.

Falco is an open-source tool developed by Sysdig, which has been part of CNCF since 2018. It detects suspicious behavior in containerized environments. It, therefore, integrates perfectly with Kubernetes.

Falco uses dynamic analysis rules and monitors syscalls. A major advantage of Falco over other HIDS (host-based intrusion detection systems) is the ability to listen to Server API events. When a potential threat is detected, Falco sends an alert providing detailed information on the event that triggered it. In particular, it can detect binary mutations, the elevation of privileges, suspicious use of SSH services, etc.

Falco is highly customizable, enabling users to create their own rules and alerts to meet their specific security needs. It can be easily integrated with other security tools and services to provide a complete security solution.

Falco is an essential element in ensuring the security of a Kubernetes cluster. We recommend setting it up as long as your teams have the time to process and configure alerts. As with all intrusion detection tools, the main difficulty is fine-tuning the configuration to produce the right volume of alerts. You need to have both qualitative alerts on the most critical rules and quantitative alerts to detect noisier attacks.

It should also be noted that problems persist with Falco's interconnection with the kernel: for example, in an EKS cluster, Falco kernel modules are generally published 2 weeks after the publication of a new AMI by AWS, which delays the update of nodes. 

We recommend this tool if your team has the bandwidth to process alerts daily. Otherwise, you'll just be feeding "alert fatigue."

Linkerd is an up-and-coming Service Mesh technology that makes it easy to implement encryption and authorization of communications in Kubernetes clusters.

Linkerd has been a CNCF "graduated" Kubernetes Mesh Service since July 2021. Linkerd promises to offer the community an extremely simple and fast Service Mesh. 

A Service Mesh is an infrastructure component that facilitates communication between microservices. It enables a number of advanced functionalities, including mTLS encryption of inter-service communications, strong observability, fault injection, etc.

Compared to other Mesh services such as Istio, Linkerd's architecture is straightforward. The main reason is that the number of Linkerd functionalities is deliberately limited and can be extended thanks to several plugins: tracing thanks to Jaeger and canary releases thanks to Flagger. Linkerd still lacks certain functionalities, notably JWT header-based routing.

Linkerd's performance is very good, thanks to its minimalist proxy written in Rust. The various benchmarks available on the Internet indicate memory and CPU consumption on the order of 10% of Istio's. 

Finally, a very important point concerning the cost of setting up this Mesh service is that Linkerd does not contain an ingress controller. This means you can add it when needed without having to change the ingressClass of all services.

We recommend you try Linkerd, which has the advantage of being much simpler to install and maintain than its better-known competitors. This Mesh service offers most of the expected functionalities, notably via the plugin system.