My question:
Security team is insisting QA team to avoid exposing username, passwords, client_secrets and other sensitive information directly in request body or through environment parameters while running postman queries.
We already implemented Azure Key Vault to manage secrets and keys for other automation test related secret management.
Is there a way we can parameterize Key and Value under request body or in environment variables and fetch those values directly from Azure Key Vault?
TIA
Hi,
Did you achieve this in your script. I am also looking for the same
To connect to Azure Key Vault in Postman, you will need to authenticate to the API.
This uses OAuth 2.0 and will have its own client secrets, etc.
Therefore where do you store those details which are also confidential?
It sort of defeats the purpose of having the secrets in the key vault, if you need to have the secrets used to connect to the key vault outside of the key vault. Chicken and Egg scenario.
I’m not going to say this is best practice, but you usually copy and paste these secrets when using them locally in the desktop or web application. When you are initially developing your collection or using it locally for troubleshooting purposes.
If you use the current value in an environment, these won’t get synched to the Postman Cloud or are included if you export the environment to store in a code repository. They are only available locally on the device (and will be encrypted at rest).
You would then usually automate this within your continuous integration pipeline.
If you are using Azure Pipelines, this is pretty seamless as you connect to the Key Vault using the service principal (so no usernames or passwords), retrieve the secrets you need for the collection as one of the first steps in the pipeline, and then send this in the command line interface that you use to call Newman or the Postman CLI).
TLDR: It is possible to connect to the Key Vault in a pre-request script or a straight up request in Postman and then store those details in a variable that can be consumed in subsequent requests, but this connection to the key vault also uses OAuth 2.0 and has its own client secrets.
Hi @michaelderekjones, Great Post.
I’m looking into doing this myself at the moment.