Hiding the secrets
Open-source credentials
Time to hide those secrets from prying eyes! The current version of the Log in
keyword in our robot code looks like this:
The credentials are just written there, available for anyone with access to the source code to see! 😱
We are being a bit too much open-source with those.
How to make them "proprietary"?
You want to replace the actual credentials with references to those credentials. The RPA Framework provides a library for this use case: RPA.Robocorp.Vault
. Add the library in the *** Settings ***
section:
Use the Get Secret
keyword from the RPA.Robocorp.Vault
library to fetch a secret by name robotsparebin
and store the secret to a variable. Replace the concrete credentials with references by accessing the properties of the secret by their name. Let's use username
and password
to make them obvious:
Wait. How did you find that keyword? Or the argument?!
The Language Server Protocol for Robot Framework provides powerful robot development features. Also, check out the Visual Studio Code extension if you like to use Visual Studio Code as your robot development IDE!
You are not sure what the keyword was? Probably something about "secret"? Well, the keyword auto-completion is pretty intelligent. Take your best guess and let it suggest you some matching keywords:
Great! But how do I know if the keyword has arguments? Or the name of those arguments? That is also covered:
And that is not all. If you have the Editor: Format On Save
enabled in Visual Studio Code, the LSP extension will handle the formatting for you. Four spaces everywhere? Check! If you have more than one developer in your team, your formatting will now stay consistent. Give it a try!
Creating a local vault file to store the secrets
The secret with the credentials does not exist at the moment. Where should we place them? And in what format? The format is just good old JSON. In this case, the robotsparebin
is the name of the secret. The username
and password
are the properties of that secret:
For local robot development, you create a JSON file somewhere outside your repository (so that you don't accidentally commit it!). Create a vault.json
file in your home directory (/Users/<your-username>
on macOS, /home/<your-username>
on Linux, C:\Users\<your-username>
on Windows) and paste the above JSON in the file.
macOS / Linux: To find your home directory, run
cd
in the terminal. Then, runpwd
to print the full path to your home directory.
Letting the robot know where to find the vault file
In the root of your robot directory, create a new devdata
directory. Inside that directory, create a env.json
file. Paste the following JSON in that file (replacing <your-username>
with your username):
macOS / Linux:
Windows:
The RPA_SECRET_MANAGER
and RPA_SECRET_FILE
are environment variables that instruct the RPA.Robocorp.Vault
library to use secrets stored in a file.
These are only used locally. In Control Room, you have other mechanisms for storing your secrets. Those secrets can be passed in from the cloud to a self-hosted Robocorp Workforce Agent and Assistants, too! For local testing, using the file for secrets works nicely.
The file structure should look something like this:
What have I done?! 😱
That was quite a few changes! Would it be great to see what you have modified, let's say, in the .robot
file? As in how did the code look previously compared to now (what was added, modified, or removed)? Here's how Visual Studio Code displays the changes; pretty neat, eh?:
Higher-level view of what is new and what is modified is also available:
You can naturally view the changes on the command-line, too! Run git diff
. This is how it might look like:
Running git status
displays a higher-level view of the changes:
Note that nothing has been committed yet. The files have been changed, but Git has not stored them in the repository. It only does it when you tell it to. Let's test the changes first before deciding whether to commit or not.
Testing the robot locally
With those changes, your robot should still work, but instead of exposing the credentials for everyone to see, it fetches them from an external file that is not stored in the repository. Run the robot to see if it still works!
Testing the robot in Control Room development workspace
Currently, both the production and development workspaces contain the same version of the robot. Now you are going to push this shiny new version of the robot to the development workspace. This way, the production workspace stays untouched and undisturbed.
Push the robot from Visual Studio Code to Control Room and run the process. It should fail! From the process output console, we see that the vault is missing: RobocorpVaultError: 404
404 is a HTTP response status code meaning "Not Found".
Creating a secret in the cloud vault
The local robot used the file-based secret for the credentials. The robot in the cloud cannot access that file on your computer. You need to provide the credentials in the cloud.
- Navigate to
Vault
and clickAdd
. - Enter
robotsparebin
as the name (the name has to match the secret name in the robot script). - Click
Add item
and enterusername
as the key andmaria
as the value. - Click
Add item
and enterpassword
as the key andthoushallnotpass
as the value. - Click
Confirm
to create the secret.
You can click on the lock icon to view the values if you want to ensure there are no typos!
Run the process
Rerun the robot. Now that the secret is available in the vault, the run should succeed!
What we learned
- Secrets should be stored in a vault, not in the code repository.
- The
RPA.Robocorp.Vault
library provides theGet Secret
keyword for easy secret retrieval. - A secret has a name and one or more key-value pairs.
- Local robots can use a file-based vault (a JSON file).
- The user home directory (
/Users/<your-username>
on macOS,/home/<your-username>
on Linux,C:\Users\<your-username>
on Windows) is one option for placing the secret file. - Robocorp Hosted Cloud Workers use Control Room vault.
- The robot runs on Robocorp Workforce Agent and Robocorp Assistants can also use Control Room vault.
- Code changes are easy to view using either visual or command-line Git clients.