Up and Secure with Backplane

Deeply personal, confidential data carries with it an implicit danger, so Identity has become one of the most important aspects of building a Network that scales.

The Network is the fulcrum of nearly anything we humans do in high-speed society, from devices on our person to oceans of data about our behaviors and activities. Security and traffic management go hand-in-hand. This is where Backplane fits in, enabling granular routing controls and environment isolation with fully managed security.

There are many integrations, definitions and use cases outlined in the Backplane Docs. This guide introduces the core concepts through real world examples as I enable SSL on my non-secure website. Reading the Docs beforehand is not necessary, but it is a useful reference for some topics I will cover. I assume some familiarity with the unix shell and basic networking concepts like DNS and webserver hosting.

Pre-Flight

First I register and login at https://www.backplane.io/signup. Two easy methods are available: either GitHub SSO credentials, or your own email address and password.

Next I install the CLI. Several installation methods are available at https://www.backplane.io/download.

My servers are CentOS-based Linux so I want the RPM, which does one simple thing: installs /usr/local/bin/backplane, owned and executable by root. There's nothing special about the binary that it needs root, in fact best practice is to run it as a different user. To keep things simple in these examples, I'll first be running it as a local user, so I need to make a change to the permissions:

Before the CLI can be used, it must authenticate with the Backplane API. Once I have registered and logged in, I can create a new Access Token. This creation page will also be opened when typing: backplane login. Note that it will do this each time it is run, so once I've entered it once, I do not need to do it again.

To see exactly what the login subcommand is doing, let's check out the command help. Typing backplane help shows the command overview, and each subcommand can be detailed by typing backplane help <subcommand>. For instance:

As described above, the command is actually taking me to create a new token, asks for input at the prompt, and then stores it in my home directory .netrc file. Since I am on a remote shell, I simply get the full URL because it cannot launch a browser:

Once entered and successfully saved in ~/.netrc, I see the message: Log in token saved successfully!

This file is normally read during the automatic login process, but here is read directly by the backplane command each time a subcommand is run. If I'm security conscious about this file or would rather use it programmatically, an environment variable can be set:

$ export BACKPLANE_TOKEN=<token>

Traffic Control

Now that I’ve logged in to the Backplane Dashboard and established trust with my Token and backplane login, I'm ready to move on to creating Endpoints and Routes. Let's dive right in:

Here I have created a default endpoint with a randomized compound name that will be automatically registered with LetsEncrypt for its certificate, here’s what happened:

• An Endpoint named amusing-techno-17.backplaneapp.io was created and registered in DNS. Any Endpoint like this (or my own, more on this later) is a DNS CNAME (or pointer) to what is called the Backplane Edge, a collection of servers load balanced by Round Robin DNS. These clusters are configured to handle traffic for all Endpoints.
• RouteID route0000 was added.
• A Weight of 100 (out of 100) is the default for the first Route that is created on any unique Endpoint. This is just like load balancer weighting: that percentage of traffic destined for this Endpoint will be sent to this Route and Backend.
• A LabelSelector was constructed. This will be used to tell the Edge how to connect to my Backend.

You can do this multiple times, and you’ll get a different dynamically created Endpoint, which represents a different LabelSelector:

Making Connections

Now it’s time to make things happen with Connect. This is just another subcommand, only this one starts its own service called the Agent and is launched by typing backplane connect <labels> <proxyurl>. Let's break this one down before I run it:

• Connect. The central intelligence between the Edge and Backends, establishing an encrypted tunnel between them.
• Labels. These should match the LabelSelector of a Route on the Endpoint, sometimes called a Backend Label.
• ProxyURL. The Backend, your HTTP site or RESTful application.

Up until now I’ve simply been following the Quick Start outlined in the Docs. However at this point in our walk-through, I’m going to veer away from that and choose not to use the local built-in webserver.

Instead, I have a copy of the front end of a website I run as a musician, sitting at a real DNS address, hosted on AWS. It’s a super simple site, but I don’t have HTTPS! As a musician who wants high ranking search results as The Network evolves and browsers begin to frown upon non-secure websites, it may behoove me to give it a cert so I’m not unfairly penalized.

So let’s face it, certs can be a pain, but are extremely important, so it’s time to get on the bandwagon. However, maybe I’m a musician who has no interest in being a website admin, or maybe I want a service that will rotate certs every so often for hardened security. Backplane is here to solve my problems, so let’s see what happens when I connect the Endpoint to my Backend (www.isochron.us) and get an automatic cert:

The Agent is in its service loop, so it will stay in the foreground of your shell, which is good for monitoring and troubleshooting when first getting things going. It has now established reverse HTTP tunnels to the discovered list of available Edge servers. In essence, I have given the Edge the context it needs to route traffic for the rational-giraffe-2.backplaneapp.io Endpoint that was defined with the “endpoint=rational-giraffe-2.backplaneapp.io,release=v1” Label that I have connected to my http://www.isochron.us Backend.

Lo and behold, I can browse securely and see my homepage at https://rational-giraffe-2.backplaneapp.io and can confirm the Backend is connected to the tunnel by viewing it in the Dashboard. Browsing securely to a hostname that has nothing to do with my actual website isn’t very useful, but this shows how simple it is to see Backplane technology in action with a few simple commands.

Planned Endpoints

So why can’t I browse securely to the original Backend? Partly because I didn’t originally Route an Endpoint that has a DNS domain name consistent with the website address that I want to secure.

Let’s re-examine the backplane route command:

Now you can see more of the power of the route command and Endpoints. You may have already guessed that in practice, the Agent lives on every Backend, and instead of controlling a tunnel from your personal shell with backplane connect, it controls the tunnel to the Backend by using a localhost address. For now, because the Agent is running on my local shell, I don't have to worry about it running on my AWS instance, the reverse tunnel is still established between the Edge and the Backend.

To make my own DNS domain addresses secure, I need to create my own Route:

with my own Endpoint:

The Backend is connected, but remember what I mentioned about the CNAME above? This is another in the chain of CNAME aliases that must be configured. In order for Backplane to configure a cert for your website address, your website address must consistently resolve to a Backplane IP address.

Since I already have www listed as a valid website and I don’t want to disrupt that service yet because I’m still using that address as my current Backend, I need to create a new CNAME record pointing to cname.backplane.io. The following example is a Terraform stanza that configures my zone in the AWS DNS service called Route53:

I did not restart my Agent, only waited a few minutes for DNS to propagate, et voila! Backplane has provisioned the cert automatically:

I have travelled far down the path of making my website secure with three simple first steps:

1. backplane route dub.isochron.us "site=www.isochron.us, version=v1, env=prod"

2. backplane connect "env=prod,site=www.isochron.us,version=v1" http://www.isochron.us

3. update DNS for dub.isochron.us to point as a CNAME to cname.backplane.io

Compare that with the process of requesting, installing, configuring, operationalizing, and managing your own cert infrastructure. I don't have to know who LetsEncrypt is or what they do, I changed no httpd configurations, I added no CA authorities, I didn't change the AWS Instances one bit. It is an attractive solution to someone who doesn't want to fool with security but holds it in the highest importance.

Dial… Out?

You’ll also notice that I did not tear down my route to rational-giraffe-2. Not only can I have a many-to-one distribution of Endpoints with a single Backend, Backplane knows how to distribute traffic from an Endpoint to multiple Backends by interpreting Weights. Multiple Endpoints may be served by multiple Backends on which the Agent dials out to the Edge to build the reverse HTTP proxy.

Wait a minute. What? The Agent goes on the Backend itself, of course, but dials… out?

Recall that I ran the Agent from a remote shell that had nothing to do with any of the resources involved. When backplane connect is run, it makes a connection to the API and dials out to the Edge, configuring a reverse tunnel with the Backend address, such that Internet traffic is actually flowing into the Backend, as you would normally expect traffic to flow. The Backend - via the Agent dialing out - started as a client and became a server.

With isolation done by the Agents themselves each sitting on a Backend, only those resources for which the Endpoint is configured are accessible by the traffic destined for that Endpoint. I could use a selection of criteria (e.g. IP filtering or GeoIP) to limit traffic to a certain DNS name (app.isochron.us) or even specific URI (app.isochron.us/file/serv?v1) as Endpoints, and because the Agent tells the Edge where the Endpoint's Backend is, the inbound traffic is only valid for exactly one route.

This makes things like A/B testing, Blue/Green deployment, and Zero Trust Identity Networks possible with minimal change to the application itself. These include more advanced topics not covered here, but appear in the Backplane Docs. Since this guide is meant to be a beginner's introduction to basic concepts and a simple walkthrough of the technology, it doesn't require coverage of these features.

Nevertheless, to accomplish any of this and not have dozens of backplane connect commands sitting on some remote shell, I need to put the Agent on my Backends and try some basic traffic shaping. Backplane offers Integration Guides for various platforms like Heroku, Kubernetes and Docker. Setting it up on Linux and something like init or systemd is not difficult, but for this exercise I will simply be running it like I did in my local shell.

Up in Weights

One thing you should notice about my original configuration is that www.isochron.us is actually a CNAME to an AWS Elastic Load Balancer (ELB) front-end with two EC2 Instances behind it — my real Backends.

In order to complete my Backplane integration, I want to remove ELB from the critical path. In this example, I will use Weights to load balance between three Backends, each connected out to the Edge with their own unique Label. The Edge then knows, because the Endpoint is the same, that Weights should be honored. Once the routes have been changed, AWS ELB will be out of the picture, and Backplane is making the load balancing decisions.

First, I configure my Routes with Labels identifying each Backend, and to make them unique I’m just changing the version number:

Second, I review initial Weights, remembering that route will automatically set the first Weight in an Endpoint definition to 100, and subsequent ones to 0:

Third, I install the Agent as before, using ssh to connect as the ec2-user to each of my Instances and installing the RPM. For a permanent setup, I would want to configure this installation at Instance creation time or use a custom image. Once it’s ready to run, I can use the BACKPLANE_TOKEN environment variable to configure API access on each, here on the one associated with route0001:

$ BACKPLANE_TOKEN=<token> /usr/local/bin/backplane connect "env=prod,site=www.isochron.us,version=v2" http://localhost:80

and then the other associated with route0002:

$ BACKPLANE_TOKEN=<token> /usr/local/bin/backplane connect "env=prod,site=www.isochron.us,version=v3" http://localhost:80

Since I haven’t used a launch environment or supervisor, I can just throw the process into the background:

[ctrl-z]
$ bg && disown

Now I can exit the shell and the Agent will remain running, which I can confirm in either the Dashboard UI or the CLI:

I can see all Backends are connected and Ready. Note that it doesn’t matter where I run query commands like this; as long as I’m authenticating with the same Token, I’ll see my account details.

Adjusting Weights is done atomically with the shape subcommand to distribute traffic across multiple Backends. In the following, I drop the Weight of the ELB Backend to 0 while equally distributing traffic directly to the two Instances themselves using 50 for each (you will get an error if the total does not equal 100):

My site at https://dub.isochron.us is working fine since all I’ve done is shifted traffic to different Backends. My original ELB site still works at http://www.isochron.us as well, so I can keep that active if I need to switch back and forth or juggle my DNS names or do rolling releases. It may not seem obvious at first, but the Agent also doesn’t care where its Edge is, so I could even flip cloud providers using creative Routes and Endpoints, or implement a complete migration from bare-metal to multiple clouds.

I hope this guide has inspired you with the possibilities of Backplane’s unique reverse tunnel design and traffic management features. As Identity becomes even more crucial to the progress of humans and The Network, Backplane is committed to providing a reliable platform for removing the anxiety over security, allowing you to innovate.

Glossary

Agent. A special mode of the CLI invoked with backplane connect, identifying the proper Route from Edge to Backend.
Backend. Your application itself, what actually gets served to the users of your site.
Backplane API. The application and database where Backplane configurations are stored.
Backplane Dashboard. Your UI view into the API and configurations.
Backplane Edge. The Backplane-owned server farm that proxies your Endpoints to your Backends.
CLI. The backplane command, how all configurations are created and managed.
CNAME. A DNS convention that allows one DNS name to resolve the the IP address of another, allowing Backplane to provision certificates for your Endpoint.
Endpoint. The web address of your HTTP-enabled site, identified by a DNS name and optional URI path.
Label. Uniquely defines an Endpoint Route through the Edge to a Backend.
LetsEncrypt. The third-party provider Backplane uses to automatically provision your security certificates.
Reverse HTTP Tunnel. A technology leveraged by Backplane that turns clients into servers.
Route. The definition of your Endpoint with its routing rules, used by the Agent for creating the reverse tunnel.
Weight. Your connection balancing rules for a single Endpoint, defined with backplane shape.

Backplane Securing isochron.us