How are you securing secrets for storing your projects in github?
We're trying to migrate our ReadyAPI suites into github and I'm getting a little stuck with ReadyAPI's documentation on how to encrypt passwords we use to test our application, I'm hoping someone has a simple answer they can share.
Our application passwords are stored in auth manager or request properties, when this project is converted to a composite project and pushed into github those values are visible so I have followed documentation to try and mask them without success.
- 1. Encrypt the project - this stops the project being a composite project so we're back to single use for upgrades and preventing people from making changes and keeping them in a branch. Doesn't seem like this fits.
- 2. Password protect the project - doesn't obsfucate the passwords anywhere.
- 3. Move the passwords to encrypted properties - Feels very hacky and clunky, makes the auth manager redundant and isn't very user friedly.
I haven't been able to find any other in application solutions other than the above, I was looking at keystores/ truststores but neither seem to fit the requirement.
This has left us with the only option we can see which is to write a groovyscript to pull the passwords out of an encrypted keepass kdbx file to use at runtime. This is not my preferred approach as I would rather use in built features with ReadyAPI support documentation... If anyone knows of other things to attempt or can share how they managed it in their project that would be appreciated.
in the case of encrypted properties, you can set up a project-level property (e.g., MyAppSecret) and then use it in the Auth manager as well:
${#Project#MyAppSecret}The property is used in Auth manager requests and masked in the logs, at least in the logs I tried.
Moreover, you can override the propery value from the command line, e.g., when you execute the test from the pipeline. So, for some environments you can include the secret and inject in the pipeline for others.
Though, if the secret fields from Auth manager would be treated as sensitive and encrypted by default we wouldn't need this. You can raise a feature request for this.
