Credentials within RightScale offer a convenient way to store sensitive or frequently used values in an easily manageable interface. It’s important to remember that RightScale credentials consist of a Name, Value and Description and are intended to be used as inputs for servers. Credentials are accessible via the RightScale dashboard as name/value pairs where the value is passed into a script or other object as any other text input would operate.
A credential is not, however, a key/value pair such as a username and password that are bound together or otherwise related. So if you wanted to store a set of login data, you would need to use two distinct credentials: one for the username and a second for the password (potentially another for domain if you are working within a Windows Active Directory environment). While the security features are nice, credentials also offer an easy way to store commonly used or complex inputs which can make managing inputs easier.
Storing Secure Information
Credentials are passed into RightScripts™ and Chef recipes in such a way that RightLink™ masks the value within the Audit Entry screen showing the log from scripts and recipes running. This is useful for storing passwords and other critical or sensitive information, but it is also important to remember that any users who have “admin” privileges within your account will be able to view the credential’s value. Those with “designer” rights will be able to use them without being able to see the actual value. These inputs will show a value of <hidden credential> when their output appears in the log.
I wrote a very simple PowerShell RightScript that writes the value of the credential out directly and then assigns the value to a local variable and writes that local variable out to the console:
*RS> RightScript: 'Credential Test' **** 09:13:26: Credential Value is <hidden credential> 09:13:26: Credential Value from local variable is <hidden credential> Credential Value from ToString() local variable is <hidden credential> 09:13:26: Script exit status: 0 09:13:26: Script duration: 0.858011 09:13:26: Chef Run complete in 0.873611 seconds
Then I’ve set the script up to run on an instance of the Base ServerTemplate for Windows (v13.0) with a credential that I created called “test_credential”:
Once the script has completed, from the Audit Entries tab of the instance of the server, we can check out the log from the process of running the script — specifically I’m looking for the three lines that were output via the Write-Host commands. Here’s the log output from just the script itself (notice that all three outputs are hidden in the log):
*RS> RightScript: 'Credential Test' **** 09:13:26: Credential Value is 09:13:26: Credential Value from local variable is Credential Value from ToString() local variable is 09:13:26: Script exit status: 0 09:13:26: Script duration: 0.858011 09:13:26: Chef Run complete in 0.873611 seconds
A couple of things to remember related to security:
- Using credentials, even assigning them to local variables, will still keep the values hidden
- Don’t forget: Only users with “admin” rights will be able to see and create credentials, while those with “designer” privileges can utilize but not see the values
Although a lot of common inputs when launching servers are sensitive (user name, password, certificates, and keys, etc.), credentials make life easier by reducing the number of times you have to actually type the values in, which reduces errors and speeds up the process of getting your servers launched. This can be helpful for the input process, but sometimes can make debugging scripts difficult in that it’s often useful to be able to write variables out when debugging.
I find that when I’m developing scripts or RightScale ServerTemplates™, I’ll use raw text inputs until I have a working product so that I can easily output the values to the console. Once the process is proven, I quickly switch over to credentials so that I can avoid making mistakes!
Some “ease of use” tips:
- Credentials are great for storing sensitive information
- Use credentials for complicated inputs or things that you’ll likely mistype if you had to input it multiple times
- Remember that you aren’t going to see the value in the Audit Entry logs — use another form of input if you’ll need to see the value in the console
- Credentials (like most things in the RightScale dashboard) will show up in alphabetical order when you open the drop-down boxes to select one. If you’re storing user name and password combinations, end the credential name with _USER and _USERPASSWORD so they show up in user/password order in the list. For example: MYSQL_USER/MYSQL_USERPASSWORD and IIS_APPPOOL_USER/IIS_APPPOOL_USERPASSWORD
Within the Load Balancer with HAProxy (v13.0) ServerTemplate, there is an option to allow for SSL offloading to happen within Apache before it gets to the HAProxy process. Under the WEB_APACHE inputs for the server, there are seven advanced inputs — four of which are related to the SSL Certificate itself which are commonly set up as credentials. In fact, the help text gives examples that reference credentials rather than text inputs.
Another example is that I’m working on a Windows-based ServerTemplate where the product I’m installing requires multiple accounts to be set up. I’ve been doing it manually while testing it, using the Microsoft Active Directory (v13.0) ServerTemplate and the AD Create a new user operational RightScript to create users and I’m simply checking down my list of credentials to speed through the process of creating the accounts:
There are a ton of great ways to use credentials to keep inputs secure and consistent throughout your deployments while avoiding the dreaded “fat-finger” input error. More information is also available on the RightScale support site, which has some great tips on how to manage credentials, and some common uses of credentials within the RightScale dashboard.
And if you haven’t yet tried RightScale cloud management, you can test it out with the RightScale Free Edition, through which you can have five users on your account and run approximately five small servers.