Earlier this year, Cloudflare acquired S2 Systems. We were a start-up in Kirkland, Washington and now we are home to Cloudflare’s Seattle-area office.
Our team developed a new approach to remote browser isolation (RBI), a technology that runs your web browser in a cloud data center, stopping threats on the Internet from executing any code on your machine. The closer we can bring that data center to the user, the faster we can make that experience. Since the acquisition, we have been focused on running our RBI platform in every one of Cloudflare’s data centers in 200 cities around the world.
The RBI solution will join a product suite that we call Cloudflare for Teams, which consists of two products: Access and Gateway.
Those two products solve a number of problems that companies have with securing users, devices, and data. As a start-up, we struggled with a few of these challenges in really painful ways:
- How do we let prospects securely trial our RBI platform?
- How do we keep our small office secure without an IT staff?
- How can we connect to the powerful, but physically clunky and heavy development machines, when we are not in that office?
Dogfooding our own products has long been part of Cloudflare’s identity, and our team has had a chance to do the same from a new perspective.
Managing access to our RBI service for early adopter customers and partners
As we built the first version of our product, we worked closely with early adopters to test the product and gather feedback. However, we were not ready to share the product with the entire world yet, so we needed a way to lock down who could reach the prototype and beta versions.
It took us the best part of six months to build, test and modify (multiple times) the system for managing access to the product.
We chose a complicated solution that took almost as much time to build as did features within the product. We deployed a load balancer that also served as a reverse proxy in front of the RBI host and acted as a bouncer for unauthenticated requests. That sat behind an ASP.NET core server. Furthest to the right sat the most difficult component: identity.
We had to manually add identity providers every time a new customer wanted to test out the service. Our CTO frequently burned hours each day adding customers manually, configuring groups, and trying to balance policies that kept different tenants secure.
From six months to 30 minutes
As we learned more about Cloudflare during the due diligence period, we started to hear more about Cloudflare Access. Like the RBI solution, Access applied Cloudflare’s network to a new type of problem: how do teams keep their users and resources secure without also slowing them down?
When members of the Cloudflare team visited our office in Kirkland, none of them needed a VPN to connect. Their self-managed applications just worked, like any other SaaS app.
We then had a chance to try Access ourselves. After the deal closed, we collaborated with the Cloudflare team on an announcement. This started just hours after the acquisition completed, so we did not have a chance to onboard to Cloudflare’s corporate SSO yet. Instead, the team secured new marketing pages and forms behind Cloudflare Access which prompted us to login with our S2 emails. Again, it just worked.
We immediately began rethinking every hour we had spent building our own authentication platform. The next day, we set up a Cloudflare Access account. We secured our trial platform by building a couple of rules in the Access UI to decide who should be able to reach it.
We sent a note out to the team to try it out. They logged in with our SSO credentials and Cloudflare connected them to the application. No client needed on their side, no multi-level authentication platform on ours.
We shut down all of our demo authentication servers. Now, when we have customers who want to trial the RBI technology, we can add their account to the rules in a couple of minutes. They visit a single hostname, login, and can start connecting to a faster, safer browser.
Protecting our people and devices from Internet threats
When we signed a sublease for our first office location, we found the business card of the building’s Comcast representative taped to the door. We called them and after a week the Comcast Business technicians had a simple network running for us.
We wanted to implement a real network security model for our small office. We tried deploying multiple firewalls, with access controls, and added some tools to secure outbound traffic.
We spent way too much time on it. Every configuration change involved the staff trying to troubleshoot problems. The system wound up blocking things that should not be blocked, and missing things that should be blocked. It reached the point where we just turned off most of it.
Another product in the Cloudflare for Teams platform, Cloudflare Gateway, solved this challenge for us. Rather than 30 minutes, this upgrade took about 10.
Cloudflare Gateway secures users from threats on the Internet by stopping traffic from devices or office networks from reaching malicious destinations. The first feature in the product, DNS-based security, adds threat-blocking into the world’s fastest DNS resolver, Cloudflare’s 1.1.1.1 product.
We created a policy to block security threats, changed our router’s DNS settings, and never had to worry about it again. As needed, we could log back into the UI and review reports that told us about the malicious traffic that Gateway caught.
As I’m writing this post, none of us are working in that office. We’re staying home, but we still can use Gateway’s security model. Gateway now integrates with the 1.1.1.1 app for mobile devices; in a couple of clicks, we can protect iOS and Android phones and tablets with the same level of security. Soon, we’ll be releasing desktop versions to make that easy on every device.
Connecting to dev machines while working from home
Back at the office, we still have a small fleet of high-powered Linux machines. These desktops run 16 cores, 32 threads, and 32GB of DDR memory. We use these to build and test Chromium, but dragging these boxes to each developer’s house would have been a huge hassle.
We still had a physical VPN appliance that we had purchased during our start-up days. We had hired vendors to install it onsite and configure some elaborate syncing with our identity providers. The only thing more difficult than setting it up was using it. With everyone suddenly working from home, I don’t think we would have been able to make it work.
So we returned to Cloudflare Access instead. Working with guidance from Cloudflare’s IT and Security teams, we added a new hostname in the Cloudflare account for the Seattle area office. We then installed the Cloudflare daemon, cloudflared, on the machines in the offices. Those daemons created outbound-only tunnels from the machines to the Cloudflare network, available at a dedicated subdomain for each developer.
On the other side of that connection, each engineer on our team installed cloudflared on their machines at home. They need to make one change to their SSH config file, adding two lines that include a ProxyCommand. The setup requires no other modifications, no special SSH clients or commands. Even the developers who rely on tools like Visual Studio Code’s Remote SSH extension could keep their workflow exactly the same.
The only difference is that, instead of a VPN, when developers start a new SSH session, Access prompts them to login with Cloudflare’s SSO. They do so and are connected to their machine through Cloudflare’s network and smart routing technology.
What’s next?
As a start-up, every hour we spent trying to cobble together tools was an hour we lost building our product but we needed to provide secure access to our product so we made the time investment. The only other option would have been to purchase products that were way outside of the price range for a small start-up where the only office perk was bulk Costco trail mix.
Cloudflare for Teams immediately solved the challenges we had, in a fairly comprehensive way. We now can seamlessly grant prospects permissions to try the product, our office network is safer, and our developers can stay productive at home.
It could be easy to think “I wish we had done this sooner,” and to some extent, I do. However, seeing the before-and-after of our systems has made us more excited about what we’re doing as we bring the remote browser technology into Cloudflare’s network.
The RBI platform is going to benefit from the same advantages of that network that make features in Access and Gateway feel like magic. We’re going to apply everything that Cloudflare has learned securing and improving connections and use it to solve a new customer problem.
Interested in skipping the hard parts about our story and getting started with Cloudflare for Teams? You can use all of the features covered in this blog post today, at no cost through September.