I am reading up on the use of api keys, secrets and the Vault in postman.
I understand that the Vault is specific to a user and from what I’ve read it is usable in Postman desktop. However, what about when I want to run a collection that uses a secret in the vault via a devops pipeline?
Here is a use case:
I have authorization keys for a cloud service. To keep the keys as secure as possible I could put them in my vault. I could then provide those keys to other people on my team so they can keep the keys in their own vaults. (Generating these cloud keys for each user isn’t feasible.) Now I want to add in a pipeline to automatically run a test via the Postman CLI. I could log into postman as the pipeline “user” and setup a vault under that account but I assume that since the pipeline would not be working with the desktop application that this would not work.
Is the workaround to do this?
Define these keys in the pipeline’s secret store
Pass the keys as options when using the CLI
Use pre-request script check for the existence of the vault secrets and if they do not exist, use the CLI arguments
My company does not have an enterprise level account so any solutions involving linking the vault to a password service would not work for us.
If you can’t link the vault to a centralised password service like Azure Key Vault, then steps 1 and 2 would be the traditional way of doing this.
Step 3 won’t do anything, as the secrets will just not exist. They only exist for that user, on that machine. You don’t really want to have a static VM running Postman for this to work. Pretty sure if you log out of Postman then the current values will disappear making it brittle.
If you need to install the CLI client so it runs on your local network, then it should be installed on an ephemeral VM while the job is run and then deleted.
Easy with Azure Pipelines but I don’t know what CI tool or capabilities you have.
Just send the relevant secrets in the pipeline.
Setup your collection with an environment, and then set the environment to use Postman vault entries for the initial values for any relevant secrets. This will get copied to your colleagues current value when they open the collection and select the environment. All your colleagues need to do is copy and paste any relevant secrets into their local vaults for testing locally.
The pipeline will then send the relevant secrets to overwrite the current values in the environment when the job is run via the CLI.
Thanks for the gut check @michaelderekjones. Our pipelines typically use VMs that are instantiated as needed and then destroyed so no worries there. I see what you are saying about step #3 not being needed.