A fundamental problem in Cloud management is “how do I get the remote instance to do what I want it to?”. Taking this task on for a few systems is doable with a number of techniques, making it scale for many thousands is not quite as simple. At RightScale, we have been on the “bleeding edge” of this issue since the early days of cloud computing, and we have learned a lot along the way. One of those lessons has led to our implementation of the RightLink agent and the RightNet protocol.
Introduction to RightLink
RightLink (link) is the instance side agent that supports RightScale’s RightNet protocol. The agent provides an improved and secure ability to leverage RightScale to manage large numbers of instances in the cloud. In the RightScale architecture, we leverage a light-weight RightLink agent on every instance to support our latest automation features. Prior to RightLink, which was released a bit over year ago, RightScale leveraged the command execution features of SSH to perform tasks on remote instances. With the introduction of RightNet and the RightLink agent, we are no longer reliant on SSH access for instance management.
The RightLink agent communicates with the core RightScale systems using the Advanced Message Queuing Protocol (AMQP). RightNet leverages AMQP’s Simple Authentication and Security Layer (SASL) support to perform a basic session authentication to ensure that the RightLink agent is talking to a legitimate RightScale core component (a broker in our lingo). This session authentication uses a shared key to authenticate the ends. After the session is authenticated RightNet uses payload encryption (openssl with X509 certificates, PKCS7 envelopes and AES 256 CBC cipher for encryption) to protect that data while in transit, and to provide a much stronger authentication mechanism (public-private key versus only the shared key of the session). Both of these security features are to ensure that packets are properly segmented and protected in the highly multi-tenant aspect of the cloud.
All our version 5 (v5) RightImages (and Multi Cloud Images, MCIs) include the RightLink agent by default. We started releasing v5 images over a year ago, and have seen a large, but not complete, adoption. For those of you still on v4 images, I am going to try to give you a couple more security motivations that may encourage you down the upgrade path.
- Ability to restrict SSH access on the instance: Because RightLink does not use SSH you can restrict access to the ssh service on Linux systems. With non RightLink enabled images (i.e., v4 and earlier by default), the RightScale platform ran scripts on the instance by ssh-ing into that instance directly, thus the need for ssh port to be accessible on the instance from the RightScale platform usually meant that it was accessible from any IP address. This created some exposure with potential brute force attacks. I will say that by default, RightImages configured SSHD to support public-key authentication only, so the risk of brute force password guessing was not an issue. What was an issue was that any vulnerability found in the SSHD server would then be potentially exploitable by anyone on the Internet. With RightLink, this exposure can be mitigated.
- Managed SSH: In addition, v5 RightImages introduce a “Managed SSH Login” feature. This allows you to use a different SSH key for each user logging into a server. It can either use an SSH key uploaded by each user or the dashboard can generate a key for each user. When using EC2 you may still select an EC2 SSH Key when launching the instance, however, it’s only really necessary if you need to log-in before RightLink starts to troubleshoot something in the bootstrap process. Note that the SSH connection is from your desktop system (wherever you are running the dashboard UI from, not RightScale) to your instance, thus working seamlessly with any SSH access restrictions you put in place.
SPOILER-ALERT: one of the items we are working on for RightLink v5.8 (next version coming out) is a Managed SSH Login that will bind each RightScale authentication principal to a distinct, non-root Unix user whenever they login via the dashboard. This is intended to improve the login auditing as well a enable each user to load a customized shell profile. We’d be very interested in your feedback as to the usefulness and desire of this specific feature.
The cleanest and best way to move to v5 images is to find a v5 ServerTemplate, clone it and make the modifications needed to effectively duplicate the functionality you currently have. This will work like a charm if you if you did your scripts right and took a modular approach to deployment.
Next option is to change the RightImage (i.e. Multi Cloud Image, MCI) you’re using to a v5 one and relaunch. The V5 execution of RightScripts is almost fully compatible with v4 so, in theory, that’s all you need to do. The catch typically is that this brings updated versions of the OS and packages with it and may cause some incompatibilities. You will probably spend a bit more time troubleshooting this avenue.
Lastly, you can get RightNet support by RightLink enabling your v4 instance (see http://support.rightscale.com/12-Guides/RightLink/04-Creating_RightScale-enabled_Images_with_RightLink), and many might be motivated to go that route. I would encourage you to move to v5. While you’ll get the “not using ssh for command and control” benefit, you will miss many other benefits of the v5 image update.
Because there are some really cool features in v5:
- Managed SSH
- Bug fixes
- Faster Execution of Operational Scripts
- Added Chef Support in addition to RightScritps
It will take a bit of effort, but I guarantee the improvements you gain will be worth it! My one-liner of advice to those RightScale customers with older versions ”if you’re one of those hanging onto v4 or earlier you really should upgrade.”