Rocket.chat + Constellation
How to set up always-encrypted Rocket.Chat
Confidential computing, with the help of Constellation, can help users create an always-encrypted Rocket.Chat, protecting sensitive data such as metadata, server configurations, and code.
Rocket.Chat is an open-source communications platform reminiscent of a self-hosted slack alternative. On its website, it positions itself as a "secure and compliant communications platform".
A key offering of Rocket.Chat is end to end message encryption. While securing messages provides significant protections, message encryption doesn't protect additional potentially sensitive data such as metadata, server configurations, code etc. At the same time, there are some downsides, including not having search capabilities and users needing to manage the key manually.
Consequently, different infrastructure-based attackers, for example someone with root access to a K8s node, can still learn and manipulate a lot. In fact, such an attacker could even inject malicious JS into client sessions and leak Rocket.Chat's E2E encryption keys or plaintext messages or just disable encryption. Thus, Rocket.Chat's E2E encryption mostly helps against passive attackers who are able to read or intercept some server-side data.
Confidential computing provides a more far-reaching solution for application encryption.
It is a groundbreaking technology that ensures that data is always encrypted, even during processing. If applied correctly, confidential computing can shield even complex applications from the cloud infrastructure. Not even system administrators, cloud provider employees or privileged attackers can access workloads protected this way. And this property can even be verified remotely. Basic confidential-computing features are readily available on major clouds like Azure, GCP, and AWS. However, these basic features cannot protect complex and scalable applications like Rocket.Chat.
For this, you need a solution like Constellation. Constellation is an open-source software that protects entire Kubernetes deployments end-to-end with confidential computing on public clouds. In essence, Constellation can shield and runtime-encrypt any application that can run on Kubernetes. Running Rocket.Chat on Constellation ensures that our entire deployment, including MongoDB and all other components that we install are shielded from the infrastructure and that all data is always encrypted.
Read on for a technical tutorial on how to set up fully-encrypted Rocket.Chat
Tutorial: How to set up "always encrypted" Rocket.Chat on Kubernetes
Rocket.Chat is an open-source communications platform, a self-hosted alternative to Slack. Its website touts it as a "secure and compliant communications platform".
Rocket.Chat can thus be made fully encrypted by running it within Constellation on confidential computing enabled hardware, which is available in Azure, GCP, and AWS.
You can see a demo of the fully encrypted Rocket.Chat in action at: https://rocket.edgeless.systems/home.
Prerequisites and Overview
In order to run Rocket.Chat on Constellation, you will need:
- A cloud provider with confidential computing capabilities
- A domain registrar to set up a domain name for your cluster
- kubectl and helm installed on your machine
The process is composed of three key steps:
- Setting up Constellation
- Setting up the domain
- Installing Rocket.Chat via Helmchart
For the sake of clarity, we have written the instructions below as someone using Azure with a Godaddy registrar, however, this tutorial can be completed with any of the major cloud providers (AWS, Azure, GCP) and a registrar of your choice.
Set up Constellation
After connecting to your cloud provider, download and install the Constellation CLI.
Once this is installed, create the constellation cluster.
This process is described in detail in the Constellation docs.
constellation config generate azure constellation iam create azure --region=westus --resourceGroup=constellTest --servicePrincipal=spTest --update-config constellation create -y constellation init export KUBECONFIG="$PWD/constellation-admin.conf"
You can now connect to the cluster with
kubectl or other tools using the auto-generated
constellation-admin.conf. The config ensures that the connection "confidential" and terminates inside the correct cluster. This ensures that no man-in-middle attack is possible.
Installing Rocket.Chat (automated)
In the case of our example setup (Azure with Godaddy), you can install Rocket.Chat using a premade Helm chart that we've created that configures the URL and with TLS.
While this can also be done manually through one of Rochet.Chat's official Helm Charts, we recommend using the Edgeless System's Helm Chart for a quicker overview of the entire process.
The chart details how each component needs to be configured. After you set your desired hostname in the values.yaml, the chart can be installed as follows (assuming GoDaddy as domain provider):
export GODADDY_API_KEY=<your creds here> export GODADDY_SECRET_KEY=<your creds here> export MONGO_USER_SECRET=$(openssl rand -base64 32) export MONGO_ROOT_SECRET=$(openssl rand -base64 32) export OWNER_ID= <your name here>
With your credentials in place, you can go ahead and run the necessary helm commands.
git clone https://github.com/edgelesssys/constellation-rocketchat.git cd constellation-rocketchat helm dependency update ./rocketchat helm upgrade rocket-infra ./rocketchat --install --namespace default --set infra.enabled=true --set apiKey=$GODADDY_API_KEY --set secretKey=$GODADDY_SECRET_KEY helm upgrade rocket-app ./rocketchat --install --namespace default --set app.enabled=true rocketchat.mongodb.auth.password=$MONGO_USER_SECRET --set rocketchat.mongodb.auth.rootPassword=$MONGO_ROOT_SECRET
The result is publicly accessible at the URL that you set.
You can see the Edgeless Systems version at https://rocket.edgeless.systems/ Feel free to come over and say "hi!"
What does this give us?
Running Rocket.Chat on Constellation ensures that our entire deployment, including MongoDB and all other components that we installed above, is shielded from the infrastructure and that all data is always encrypted.
What does this mean?
Constellation ensures that all K8s nodes run on AMD-based Confidential VMs (CVMs). CVMs are strongly isolated from the host and remain encrypted in memory at runtime. Constellation also ensures that all nodes run the same minimal mkosi-based node image.
How does Constellation ensure these properties?
Constellation leverages the hardware-based "remote attestation" feature of CVMs. The Constellation CLI uses remote attestation to verify the first node in the cluster and to bootstrap a secure connection to the cluster. All subsequent nodes that are created in the cluster are verified by existing ones. During the verification process, it is checked if a "good" node image is running on "good" hardware with a "good" configuration. Constellation knows what a "good" node image is, because we sign and publish the measurements (i.e., hashes) of each node image we release.
Once a node has been verified, it gets access to a Cilium/Wireguard-based VPN, which is shared by the nodes. A verified node also receives a key for storage encryption. Nodes ensure that all data they write to the network or to storage is encrypted. The K8s admin doesn't have to deal with key management. It all happens automatically.
If we put all of this together, we get a K8s cluster that
- keeps all data encrypted on the network, in storage, and in memory.
- is isolated from the underlying infrastructure (incl. hypervisor and host OS).
- is verified based on "remote attestation".
The Constellation docs have more details on the architecture and security features.
What about user connections?
Users connect to Rocket.Chat via the browser, e.g., by browsing to https://rocket.edgeless.systems/. TLS connections to Rocket.Chat on Constellation terminate inside CVMs, so the encryption is end-to-end.
But how does the user know for sure? Unfortunately, there is no direct way for the user to tell. However, they can manually inspect the TLS certificate (by clicking on the lock symbol in the browser bar) and confirm with their peers if its the expected certificate. The SHA-256 fingerprint of the Edgeless Systems server created in this tutorial is
CB 2C 2D 96 E6 B2 59 9D DC FD 99 C5 7A 80 58 60 3C A1 22 99 6D 28 BF FA AD 5B F0 52 EF F0 31 C5.
Ideally, a browser plugin would exist that would allow pin a certificate for a domain and even be able to verify hardware-based remote attestation statements. This is future work. Even without such a plugin, Rocket.Chat on Constellation protects against many types of infrastructure-based attackers and accidental data leaks.
Interested in learning more?
Reach out to us for an in-depth presentation of Constellation or to discover the opportunities offered by Edgeless System's tooling.