Encryption of cloud control plane communications¶

Available since MOSK 23.2 TechPreview

In a cloud infrastructure, the components comprising the cloud control plane exchange messages that may contain sensitive information, such as cloud configuration details, application and cloud user credentials, and other essential data that an attacker can use to highjack the cloud. Encrypting the control plane traffic is crucial for data confidentiality and overall security of the cloud.

MOSK offers the ability to encrypt its control plane communication by means of encapsulating the in-cluster traffic of the underlying Kubernetes into a WireGuard mesh network built across its nodes.

Untitled Diagram

Benefits of the WireGuard encryption¶

When an attacker is able to intercept the traffic between the nodes of a MOSK cluster but does not have access to the nodes themselves, WireGuard ensures the following:

Data confidentiality
Any intercepted traffic remains unreadable, especially the traffic of those components of the MOSK control plane that do not enable SSL/TLS encryption on the application level and rather rely on the underlying networking layer.
Data integrity
Alterations in traffic are detectable, ensuring that no tampering has occurred during transit.
Authentication
Only machines with valid cryptographic credentials can join the network and exchange data.

Communications protected by WireGuard encryption¶

The following control plane components can have their communications protected with the WireGuard encryption:

OpenStack database (MariaDB)
OpenStack message bus (RabbitMQ)
OpenStack internal API
OpenStack services interacting with auxiliary components, such as memcached, RedisDB, and PowerDNS
Interaction between StackLight internal components, including collection of metrics from OpenStack, Ceph, and other subsystems
Tungsten Fabric auxiliary components that include ZooKeeper, Kafka, Cassandra database, Redis database, and RabbitMQ

Communications not protected by WireGuard encryption¶

All components of the cloud control plane that require explicit firewall rules configuration as per MOSK firewall configuration guide utilize the Kubernetes host network mode for their pods, and, therefore, cannot be protected by WireGuard.

Enabling the WireGuard encryption¶

By default, the WireGuard encryption of the control plane communications is not enabled in MOSK. However, it is possible to enable the encryption upon initial deployment or later.

For the details, refer to Mirantis Container Cloud: Enable Secure Overlay considering a certain downtime for the cloud control plane.

When enabling WireGuard, make sure to configure the Calico MTU size correctly. It must be at least 60 bytes smaller than the interface MTU size of the workload network.

How the WireGuard encryption works¶

Protocols and ports:

WireGuard operates on UDP and uses a single port for all traffic. Usually it is port 51820. Therefore, ensure that this port is open in your firewall.

See also

MOSK firewall configuration

Key generation, distribution, and rotation:

WireGuard uses public-private ECDH key pairs for secure handshake between the nodes of the cluster. Each node obtains its unique pair, with the public key shared across other nodes. A key pair persists indefinitely unless the node is reprovisioned and re-added to the cluster.
The handshake procedure establishes symmetric keys used for traffic encryption and automatically re-occurs every few minutes to ensure data security.

WireGuard encryption characteristics¶

Characteristic	Details
Handshake	WireGuard uses the Noise_IK handshake from Noise framework, building on the work of CurveCP, NaCL, KEA+, SIGMA, FHMQV, and HOMQV
Cipher	WireGuard uses the ChaCha20 cipher for symmetric encryption, authenticated with Poly1305
Key length	The symmetric encryption key length is 256 bits

Impact on cloud performance¶

While WireGuard is designed for efficiency, enabling encryption introduces some overhead.

Caution

The impact can vary depending on the cloud scale and usage profile.

You may experience the following:

A slight increase in CPU utilization on the MOSK cluster nodes.
Less than 30% loss of network throughput, which, given the cluster is designed according to Mirantis recommendations, does not impact control plane communications of an average cloud.