Our new access portals, available on Elasticsearch, RethinkDB and Redis have had people asking us which one should they use, so we thought we'd explain the differences and show where they fit.
First a refresher on what the Compose access portals do. Databases like Elasticsearch, RethinkDB and Redis have historically tended to run on private networks, assuming a friendly network and not having user authentication or minimal security. If you just put these databases onto the internet raw, you'd find them full of archived cat images pretty quickly. At Compose, each database deployment gets its own virtual private network to keep it, and its contents, safe. But that brings up the problem of how to get to the databases from the internet, and thats where the access portals come in.
Access portals are specialised nodes on the private network with an external IP address. We've isolated the security responsibility into these access portals, so there's no other processes running on them but the processes needed to manage and control the transit of traffic from the outside world into the private network. We have got two types of access portals currently available, the TCP/HTTP portal and the SSH portal.
The TCP/HTTP Portal
The TCP/HTTP portal runs a web proxy, haproxy to be exact, which only accepts HTTPS connections from the outside and requires that the connection is authenticated with a username and password. It then forwards the request into the private network and returns the response.
The proxy automatically follows which system is the current primary node in the database's cluster of nodes and sends the traffic to that node. This is great for giving users web and REST access to your database without requiring them to have a lot of information to configure their connection.
By default, the TCP/HTTP portal accepts connections from anywhere on the internet but will still need a valid username and password to let traffic through. There's an IP whitelist facility which lets you block all traffic unless it's coming from an IP address in the whitelist too. Again, you'll still need valid credentials to get a connection. We have been asked if we could drop the requirement for authentication when the whitelist is in operation but a source IP address is relatively easy to fake so we won't be allowing that.
The SSH Portal
The SSH portal runs an SSH daemon configured to allow tunnels to be created from the outside into the private network. To configure tunnels like this, connecting systems must be in possession of the private part of a key and have registered to public key with the SSH portal. Then the remote system can run SSH and authenticate itself with the access portal securely – even if the public key falls into the hands of black hats, thats not enough to get access to the system. The connection process is also automatic so can be seamlessly integrated into your application architecture.
The added bonus to this more complex authentication is that you can configure any port on your local system to be mapped to any host/node and port in your database cluster using the SSH tunnelling command options. For an example of how to configure this, see "Connecting to Compose’s RethinkDB Deployments with SSH" where we work through the process for RethinkDB. There, each one of the hosts in the RethinkDB cluster gets it's own local IP address and then port 8080 and 28015 are tunnelled across to each, connecting the web interface and the application client driver to the database. You can configure the SSH portal with a one to one mapping or configure so that all your nodes are visible to your application. We'll look at some more complex configurations in a future article.
Best of both
You can, if you want, run both access portals side by side, giving you the convenience of the TCP/HTTP portal with it's name/password authentication along with the added security and powerful configuration options of the SSH portal. Do remember that our database plans include only one access portal and an extra access portal will cost $9/month extra – for most users, one or other of the current access portals will fit your needs.
These are also only the first of our access portals. We have more in development which will offer further ways to access your databases with new security and connectivity features. With Compose's platform for database-as-a-service you can be assured that these future features will, like the current options of TCP/HTTP and SSH, be just a click away.