Like any other financial system, ensuring top-notch security in all our products is crucial. A single vulnerability could expose millions of users to risks, such as identity theft and fraudulent transactions.
This article will explain how cilium Transparent encryption is being adopted as a significant step towards protecting sensitive data. It ensures that the sensitive payloads remain confidential.
Securing communication between pods (on different nodes) is essential to prevent intruders from snooping. The same can be achieved in multiple ways:
- Enabling TLS across microservices
- SASL (authentication)
- Encrypting and Decrypting payload
- Using CNI plugins such as Cilium
With the help of Cilium, we can enforce security policies directly on the Linux kernel level, which means without any changes to the application code or container configuration. By leveraging Linux eBPF, Cilium retains the ability to transparently insert security visibility + enforcement, but does so in a way that is based on service/pod/container identity (in contrast to IP address identification in traditional systems) and can filter on application-layer (e.g. HTTP). As a result, Cilium not only makes it simple to apply security policies in a highly dynamic environment by decoupling security from addressing but can also provide stronger security isolation by operating at the HTTP layer in addition to providing traditional Layer 3 and Layer 4 segmentation.
As updating the CNI plugin is a more viable option, cilium has been chosen for this purpose. Another contender was Calico. Cilium had a plus point on observability with Hubble UI which was one of the reasons why we chose Cilium over other CNI plugins.
Transparent encryption is not currently supported when chaining Cilium on top of other CNI plugins. We need to ensure that generic CNI is present for cilium to work.
- Using the cilium helm package, the cilium agent is installed on all Kubernetes nodes [control plane and worker nodes].
- Cilium is not installed on a non-Kubernetes node such as Oracle, postgres, etc
- The cilium agents intercept the outgoing packets, encrypt them, and send them through a tunnel which will be received by another cilium agent(on a different node). The cilium agent at the receiving end decrypts the packets and sends them to the upper layers.
- Packets are not encrypted when they are destined to the same node from which they were sent(i.e. will be routed with loopback). This behavior is intended. Encryption would provide no benefits in that case, given that the raw traffic can be observed on the node anyway.
- Secret key generation: A Kubernetes secret should consist of one key-value pair where the key is the name of the file to be mounted as a volume in cilium-agent pods, and the value is an IPSec configuration in the following format: key-id encryption-algorithms PSK-in-hex-format key-size
We have used GCM-128-AES. However, any of the algorithms supported by Linux may be used.
Originally published at https://medium.com on May 2, 2024.
