There is an important topic that should be discussed as part of any software deployment: security. What level of security is right for your organization? Proofs of Concept may not use any, whereas mission critical production applications should be secured in the strongest way possible. No matter where you fall on this continuum, one property of security in your deployment has pretty much always remained true: you have to “turn on”, or enable it. It’s time to raise the bar for security. With REX-Ray 0.9, TLS encryption and Token Authorization is enabled by default and without additional configuration.

REX-Ray has had full support for TLS ever since REX-Ray embedded the libStorage project and moved to a client/server model with the 0.4 release. But why is it needed? As an example, when ‘rexray volume’ is issued at the command line, that command is sent to a libStorage Controller that is hosting the libStorage API. With the client/server model, the Controller could be on the same physical or virtual machine or it could be across your network. Security conscious administrators could make sure that traffic was encrypted with TLS, however, setting up the certificates and keys is not trivial and is often overlooked. REX-Ray 0.9 is now enabling that encryption out of the box in a painless way.

What exactly is enabled by default?

When the Controller starts, the new default behavior is to encrypt all traffic with TLS 1.2. In order to do this, the Controller needs a private key and a public certificate signed by that key. If the Controller has not been configured to read an existing key and certificate, the Controller will automatically generate them. This is referred to as a “self-signed certificate”. Using a self-signed certificate means that traffic between the Controller and any REX-Ray clients will now be encrypted.

It would be a disservice in an article about security to imply that self-signed certificates provide a high-level of security. While traffic may now be encrypted, certificates serve an additional purpose — verifying who the server is. A self-signed certificate can be generated to say that it is any domain name, be it www.google.com or www.delltechnologies.com. But no browser is going to believe that certificate unless it is signed by a trusted third party, referred to as a Certificate Authority (CA). This is why it is still critical that when deploying production services, certificates signed by a trusted CA must be used.

Even with a self-signed certificate, REX-Ray 0.9 includes a fingerprint feature that helps prevent an attacker on your network. This helps thwart malicious users from using their own self-signed certificate to claim that they are the real REX-Ray Controller that has been deployed. When a REX-Ray client first connects to the Controller, a fingerprint of the Controller’s certificate is generated, and the user is prompted to trust this Controller. Once trusted, the fingerprint is stored and compared to the fingerprint of the Controller on all future TLS connections.

In this way, if a nefarious actor is able to redirect your REX-Ray traffic to a different location, you’ll get another prompt about whether you trust this new certificate. Unless you know the Controller is using a new certificate, you should reject it. For those readers who are familiar with REX-Ray deployments and are concerned that a prompt is required in order to accept the Controller’s cert for the first time, it is possible to insert the fingerprint into the client config file ahead of time.

Authentication of Clients

From completely disabled (who are we to say you *have* to encrypt, we just think you should), to using existing certificates signed by a CA, there is choice in configuring your level of encryption. What’s more, there is support for client certificates, meaning that any client contacting the Controller has to present a valid certificate to the Controller. This provides a form of authentication in addition to encryption because the client certificate identifies the client. REX-Ray 0.9 also introduces support for Tokens, an encoded string that also uniquely identifies a client. While Token support warrants a blog post of its own, the takeaway is that either Tokens or client certificates can be used for authentication, and the Controller can use that information to control which services a client has access to. For example, perhaps only certain clients can access the GCE Persistent Disk service that creates volumes on SSDs rather than magnetic disks.

There has been a worldwide focus on encryption, in part due to efforts by organizations like Let’s Encrypt. Making sure that traffic between software services cannot be read by third parties used to take reading through piles of documentation and issuing obscure commands. Now with REX-Ray 0.9, it’s never been easier to ensure that your REX-Ray network traffic is encrypted from the moment you install.