Forum Discussion

barto's avatar
barto
New Contributor
2 years ago

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. 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. 2. Password protect the project - doesn't obsfucate the passwords anywhere.
  3. 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. 

Configuration
Function Tests
SOAP
Test Setup
  • KarelHusa's avatar
    KarelHusa
    2 years ago

    barto,

    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.

     

  • KarelHusa's avatar
    KarelHusa
    Champion Level 1
    2 years ago

    barto,

    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.

     

  • nmrao's avatar
    nmrao
    Champion Level 3
    2 years ago

    You can use the project level property, as KarelHusa suggests,  to hold the data, but the value of the sensitive data should be emptied (irrespective of value being encrypted or not) before pushing the project to repository or sharing with other people.

     

    One can provide the property value either by command line as KarelHusa said, or using the property file without modifying the project.

    This way, each engineer can use their credentials when executed on their machine.

    However, if the execution is on common machine such as CI/CD, it may not work because the commands are logged.

     

    Otherway is to use public key if supported or to have a common special(non-human) user for build pipeline purpose so that it does not affect even if every one knows the credentials.

    • KarelHusa's avatar
      KarelHusa
      Champion Level 1
      2 years ago

      nmrao, good points. 

       

      In CI/CD pipeline you can also use secrets that will be masked in pipeline logs.

       

      Sensitive information must be treated as secret at all levels: CI/CD execution, inside ReadyAPI, server logs, etc.

       

  • barto's avatar
    barto
    New Contributor
    2 years ago

    Thanks both, gone with KarelHusa's solution, it allows me to get this into our companies GIT and get more hands on it. I'll have to explore if ADO is showing the credentials at a later date so may come back to your recommendation in the future nmrao