How we can keep other secrets key/credentials out of the code and supply them via Github Secrets

Your question may already have an answer on the community forum. Please search for related topics, and then read through the guidelines before creating a new topic.

Here’s an outline with best practices for making your inquiry.

My question:
how we can keep other secrets key/credentials out of the code and supply them via GitHub Secrets. So basically, we are running the Postman collection on GithubActions and those collections do contain some confidential info that we would like to avoid passing it via Postman and instead pass it directly via GitHub Actions.

To Elaborate, we have a base URL

https://John-#[email protected]/

where John-#010102 is confidential (PS: It’s just an example) and I would like to avoid passing it via the postman.

I have found a way to keep that information secret via Postman Introducing the Secret Variable Type in Postman | Postman Blog but wondering if we could have another way too.

As you’ve discovered, you just create environment variables for the elements you want to keep secret.

Ensure you set the type as “secret”. This will prevent any data being copied to the code repository or Postman Cloud. That is step 1.

Your CI tool (Jenkins, Azure Pipelines, etc) should then retrieve the secret from GitHub secrets (or Azure KeyVault) as part of the pipeline and then send those details to the Newman command line.

I use Azure Pipelines and Azure KeyVault. As they are both Microsoft tools, they integrate seamlessly. In Azure, you don’t really use passwords anymore. You setup service principals and its these service principals which runs the pipeline and has access to the KeyVault. You can also include a certificate.

I also like Azure KeyVault, as I can run an Azure PowerShell runbook that periodically changes any test account passwords, which keeps the infosec bods happy.

The other way of doing this is to have encrypted secrets in a file with the pass phrase being stored somewhere else. Your pre-request script would do the decryption and then store the results in the environment variables for that run. This does work, but its a lot of code and error handling.

I prefer using pipelines and a secret store\database of some sort, as it means the Postman collection is less complicated. (Less things to break, and easier to troubleshoot).

1 Like

Thank you for your valuable input. I was wondering, is there a way to generate a secret environment API KEY so that we can add it in Github Actions under actions secret?

To elaborate,

I have secret variable name as test-secret-pass in postman

In GitHub Actions → Action Secret,

Do I need to create a new secret in GithubActions as test-secret-pass? If yes, what would be the value? Do I need to generate any API KEY via Postman for that or I could pass the actual value of test-secret-pass?

In nutshell, I do not have a good understanding of the integration that is required to use Postman Secret variables. I am not sure how secrets would be used by github actions.

And also is it required to export global variables and add them to the JSON collection or repository that I am running? If yes, what would be the folder structure?

The secrets in Githubactions are just the variables that contain confidential information that you want to send in the pipeline, that you don’t want stored in the Postman Cloud or your CI code repository.

You retrieve those secrets\variables as the first step in your CI pipeline and configure the Newman command line to accept those variables.

With V11 of Postman, we have introduced the Postman Vault (Store secrets in your Postman Vault | Postman Learning Center), which allows you to store your sensitive data in an encrypted local vault that is not synced with the Postman Cloud. Also, we have added multiple security features to help prevent accidental exposure of your API credentials.