WireGuard is not only for VPN…
WireGuard is a fast, modern, and easy-to-setup VPN solution, but it can be used to setup ‘Encryption in Transit’ within the private or internal network.
Context
- The SOA-based solution was built almost 7–8 years back
- live environments for a number of customers.
- There are several technology stacks involved, including Windows, Linux, Tomcat, Java, Oracle DB, ActiveMQ,.NET, Apache Camel, Couch-base, and others.
- It is very hard to bring any kind of change to the solution at this stage.
- Solutions are predominantly run in data centres.
- The transition to Azure Cloud, Containers, and Azure Kubernetes Services (AKS) started.
- Not all services can be containerised, and some of the services are still running on VMs.
As the shift is happening towards adopting Public Cloud ; Zero Trust principle has become more important than ever. Encryption at REST and Encryption in Transit are now the key requirements . Encryption at REST is already taken care but there is a question on how to achieve ‘Encryption in Transit’ with minimal impact on the solution. In this context, the review of WireGuard is done to understand what is really encrypted and what is not.
Note : This post does not focuses on how to implement those configurations.
What is WireGuard ?
WireGuard is a simple yet fast and modern VPN solution which uses the state of the art cryptography.
A VPN connection is made simply by exchanging very simple public keys — exactly like exchanging SSH keys — and all the rest is transparently handled by WireGuard.
Read more about how it works at https://www.wireguard.com.
WireGuard can be configured in various different configurations as below.
Configuration 1 — VM Based Model
This is the most basic model with WireGuard. A WireGuard server is installed on the server VM, and a WireGuard client is used to configure all the necessary details of connecting to the WireGuard server. Once the connection is established, the traffic flowing through the connection is encrypted.
Configuration 2 — WireGuard with Containers
This is a slight variation of the earlier configuration where the Docker containers are used for both the server and client.
It is possible to use a non-docker client to connect to the docker-based WireGuard server (WG server).
Configuration 3 — WireGuard in Mesh Topology
Earlier WireGuard configurations depict the client server model, but it is possible to create a peer mesh network as shown below.
In this model, you are not necessarily looking at a VPN per se but would like to leverage encryption behind the scene.
Encryption happens at the network level using the wireguard network interface and using the public keys configured earlier . Encryption is transparent to the applications running on the node. There is no code change and encryption in transit is achieved in a non-intrusive manner.
Configuration 4 — WireGuard with Azure Kubernetes Service (AKS)
- All application services are running within AKS as Pods
- WireGuard is configured using Calico WireGuard.
For enabling WireGuard for AKS cluster refer the link below.
Here we should note that:
- Pod to Pod communication across different nodes is encrypted
- Node to Node communication is encrypted
- Pod to Pod communication across the same node is not encrypted
One has to carefully review this, as if your expectation is that all the communication between the pods should be encrypted, then that is not the case here.
Configuration 5 — Hybrid Model — Services in AKS + Outside AKS
- In this configuration some services run on the VM which is outside the AKS cluster.
- There is a requirement where some Pods need to access the Services running on the VM. This is certainly possible but can we use the WireGuard to encrypt this communication .Is this communication encrypted ?
It turns out this scenario is not supported currently. This is something on Project Calico’s radar and roadmap. If this is supported, then one could use WireGuard as an encryption stack whether the services are running within the cluster , outside the cluster, or in the hybrid model, which should greatly simplify the solution.
The point to be noted here is that it is not WireGuard’s limitation but something that is not supported in the Calico-WireGuard integration.
So what are some of the alternatives ?
Option 1 — Service Mesh
Service mesh does support this kind of hybrid model.
(e.g., Istio : https://istio.io/latest/docs/setup/install/virtual-machine/#start-istio-within-the-virtual-machine, Hashicorp Consul — https://www.hashicorp.com/blog/exploring-hashicorp-consul-service-vm-workload).
If the software had already been in the development phase, then it was quite natural to use Service Mesh. However, as the software is at the other end of the spectrum , with multiple live deployments , it is going to be tricky to bring in the Service Mesh at this stage. Though Service Mesh is non intrusive , the overall impact on the solution needs to be analysed before putting it into larger development steram. The nature of the project and the enterprise also poses additional challenges (non technical) to adopting this easily.
Option 2 — Encryption using Custom Certificates
This option requires the use of custom certificates and makes it accessible to Pods and VMs alike. This option requires you to take care of the management of certificates (creation, storage, distribution, rotation, etc.). This does not sound like introducing a new technical stack altogether, but it certainly adds complexity to the solution.
Summary
The obvious use case for WireGuard is to setup a VPN , however it is also possible to use WireGuard for Encryption in Transit. For e.g. To achieve ‘Encryption in Transit’ for workloads running in Azure Kubernetes Service (AKS) .
All the inter-node communication is encrypted using WireGuard. However, when it comes to encrypting traffic to services outside the cluster, Calico + WireGuard does not support encryption via the WireGuard Interface. In this case, we need to look at other options , such as Service Mesh or a traditional certificate-based solution.
