Secret Handling using Robot

Robot Framework
1

Hi all,
I am searching the www and all kinds of resources around robot. I am missing a best practice approach how to handle secrets to ensure that they are always obscured, never logged, and never stored. I wonder if I am missing something? But shouldn’t this be a basic feature?
E.G. on command line I would expect that some like following exists:

robot --secret MY_SECRET:my_secret_value ./some-tests

Is there something available?

2

Hi Martin

In the Variables section of your robot file you can create a variable with a dummy value like this:

*** Variables ***
${MySecret}			ThisIsNotReallyIt

Then when you run the robot command you can override the value with

robot --variable MySecret:my_secret_value ./some-tests

The only real problem with that is when you run your test and use ${MySecret} it will be stored in the log.html / output.xml

That can be worked around as shown in the Sensitive Input example this thread:

I think combining both those should give you what you’re after,

Dave.

1 Like
3

Hi Dave,
Thank you for confirming that this is the best way to do it.
But this means that I manually have to take care to remove all effected keywords. So, it is just a question of time till I miss one. This could lead to exposing secrets inside a CI system for weeks till I notice. And by removing the keyword I also remove insensitive data which might help debugging stuff. It feels like a workaround. What do you think?

Cheers Martin

4

Hi Martin,

It depends on the library you are using to test you app with, Some libraries have keywords like Input Password or Fill Secret, so no workaround needed

How many applications do you have in your organization? most only have half a dozen at most, so create a resource file for your app, put in a generic AppName Login keyword that handles obscuring the password, then use that keyword for the login on all your tests, you’ll probably end up with a bunch of generic application keywords, like, log out and navigation keywords, basically things you’ll use over and over again in many tests for that application. Basically you leave the Set Log Level NONE line commented out in generic AppName Login keyword while you thoroughly test it for a day or so, then when you’re happy it handles all the various login conditions um-comment that line and use the keyword in all your tests that need to login to that app.

On the CI side, does the CI have template test runners, you could add
--variable MySecret:my_secret_value part as part of the template with my_secret_value being replaced with a CI variable from where ever the CI get the secret password value.

There are other ways of dealing with it, but they all seem more cumbersome, here are some of the better examples;

  • Robot can take various types of variable files, so you could have the CI create a variable file with all the username:passwords combinations for your tests and let robot framework get them from there, and then have the CI delete the file when the test finishes (a bit risky, but not as bad as having the passwords hard coded in the test)
  • Robot can read Environment variables, if the CI can set environment variables, then you could have a standardized “appname_password” variable that the CI sets, and the AppName Login keyword mentioned above expects to exist and just uses that

Really there is no “Best” way to do things, it’s about what’s best for your organization’s requirements.

Hope that helps,

Dave.

1 Like
5

Hi Dave,
Thanks for the detailed explaination. I think I will follow this approach for know. Maybe something more convenient is coming up.
Support creating variables that are not logged even on TRACE level · Issue #4537 · robotframework/robotframework (github.com)

Cheers Martin

1 Like