As a remote-first startup, we were heavy Slack users, so considering a switch to Mattermost caused some angst for many folks on our team. And yet we switched. Why? Because of the core principles which matter the most to us:
- Permissionless innovation (which requires control, extensibility, flexibility
- Belief in open source
- Secure by design
Unfortunately, not every tool we select can be a great match with our core principles – the tool of course needs to be a great fit for the job at hand. In fact, we thought it would be a tough match in this case because reliable, robust communications solutions are critical to our ability to collaborate, and therefore ultimately integral to our ability to serve our customers with excellence. For example, we needed Mattermost needed to prove that their solution had relative parity with Slack’s reliability, performance, robust search, third-party integrations and discussion efficiency features (e.g. threaded messaging). Mattermost was up to the challenge, which meant we could make a decision based on core principles:
Permissionless innovation and belief in open source
We like to innovate, and innovation often requires extensibility, flexibility and control. Mattermost, as an open source based solution, enables innovation in a way that closed SaaS often can’t match. The world today is much different than it was before Covid-19 became part of our vocabulary. What will the world be like in 5 years? No idea. So we need the flexibility to change with an ever changing world. Mattermost open source helps give us the ability to innovate as the world changes.
We can host the Mattermost servers anywhere. We control the architecture and retain full control and visibility of each byte of data. We have direct access to the database (PostgreSQL – another great open source project). Messaging is at the nucleus of our business and security is not negotiable. This doesn’t mean we don’t use third party software as part of our security. Because we control our core data, we have the capability to securely use best in class third party software (and SaaS) in the ways which best meets our needs. Mattermost helps enable that paradigm.
Just like the open source benefits us, it benefits others. This means that helping to improve the open source – participating in the community in any number of ways – benefits everyone. This is the beauty and magic of open source, and why we are such strong believers in it (and we put our actions where our words are…we open sourced OpenZiti).
Secure by design
As a zero trust provider, zero trust is important to both us and our customers. Mattermost’s open source architecture meant we could embed zero trust networking into the Mattermost clients.
We did this using our JavaScript-based Zero Trust SDK for securing web app (and Chromium based frameworks, such as Electron) delivery with code. And only code. The JS SDK is a zero trust networking SDK which enables developers to embed zero trust networking into Mattermost clients (browsers, thick clients), without requiring agents or browser plugins.
What does that mean? As a user, when I use Mattermost from my browser, the Mattermost code (aided by the JS SDK) establishes a zero trust Mattermost connection to our Mattermost servers, without a VPN, without DNS configurations and without open firewall ports on the server side. It doesn’t matter where the users are or where the Mattermost data is – no reliance on IP addresses, VPNs, MPLS etc. – there is an embedded zero trust connection between the browser and the Mattermost server:
Ok, so user experience is better when not on a VPN (riddle: who is the only party in the world that likes VPNs and firewalls? Answer at the end of the post).
What does this mean from an administrator perspective (IT, network, admins, security team, DevOps, NetOps)? Simplification and automation. No VPNs to manage. No DNS complexity. No open firewall ports. Fully automated deployments in a complete Infrastructure as Code (IaC) model.
What does this mean from a security perspective? End-to-end zero trust which is impossible to get with any other solution. Impossible? Yes, because if zero trust is not embedded in the app itself then by definition other ‘things’ must be trusted, such as the host for example, or maybe even (shiver, shudder, shiver) a LAN/WAN, VPN concentrator or firewall. Trusting vulnerable things is no bueno from a security perspective, and neither is complexity.
So, if we eliminate that vulnerable, “bolted-on” infrastructure, then what is left? the Mattermost clients (browsers or their Electron based clients) and Mattermost servers are now unreachable to the networks. If a user session is properly identified, authenticated and authorized, then it can open a zero trust application connection. Else, no soup for you. Cool, right? And it is all enabled by Mattermost’s open source approach:
The Fabric Routers are deployed anywhere as VMs, spun up and down instantly on demand. Because both sides of the connection are opened inbound to the Fabric Routers, all the inbound firewall ports are closed (replace all the inbound firewall rules with one rule: deny-all).
Summary
Mattermost is open source based, providing the extensibility, flexibility and control necessary to enable permissionless innovation. In our case, we embedded zero trust networking into it, but the beauty is you can use the Mattermost open source to do something completely different, if you wish. Regardless, you will enjoy a robust messaging platform. As a distributed startup who is dependent on reliable, performant, effective messaging, we can vouch that you will enjoy a robust messaging platform, regardless of if or how you modify it.
Oh, the answer to the riddle: cyber attackers (bonus points if you remember what the riddle was, or didn’t speed read over it to begin with).
