Currently, variables can be set as secret to hide its plain text value in the UI.
However, developers of that workspace can easily export the environment file and keep it in their local machines.
Is there a way to disable this?
Hey @aly 
By placing the variables only in the Current Value and not in the Initial Value they will not by sync’d (Team members in the same Workspace wouldn’t see these) and they also wouldn’t be part of the Export or Forked file.
Thanks, Danny!
I’ve read that “Current values are restricted to your session within your Postman app. If you log out and log back into Postman, those values will be gone.” - How to Use API Keys in Postman | Postman Blog
Is there a way to maintain the credentials within a team, but only selected users can view the value of the secret variable?
i.e.
- I want to maintain the credentials in our Postman Team
- I want an admin to be able add/update/delete the secret variables
- I want non-admin users to be able to use the secret variables, but not view and modify them
- I want non-admin users to not be able to export the environments with populated credentials
Not sure what’s the best practice here, appreciate any advice!
Not sure you can use the variables without seeing them.
Marking them as secret just stops someone from looking over your shoulder.
Placing them in the current value stops them from being synced or exported. (Which is best practice, these values should not end up in your code repository or anywhere else).
A variable that is confidential enough to warrant this level of security should be in a key vault or similar and you control edit\view privileges at that level.
This means that the users will need to cut and paste from the key vault into the current value.
If you automate your collections through a continuous integration platform, then the first part of your pipeline would be to retrieve the values from the key vault to be sent in the Newman command line.
We use Azure Pipelines and Azure Key Vault, so this is fairly seamless with that combination.
With Azure runbooks, we also have PowerShell scripts that can rotate keys and passwords within the key vault on a regular basis.
This isn’t unique to Postman. We have the same concept when developing apps in other programming languages. The important values are stored in the key vault or another secure repository. You manually copy them locally when you are testing\building your app, and ensure that the file that contains the values locally is added to your gitignore so it doesn’t get copied to your code repository. The file then gets created as a step in your deployment pipeline when delivered to production.
A lot of the comments\topics popping up are in relation these confidential values that you really don’t want synching or being copied to the wrong places.
Postman has a shared responsibility policy in relation to data.
The recommendation is to use environments and current values to keep your confidential data out of the Postman cloud but you as they end user are responsible for ensuring this happens.
It’s not really that different to forgetting to add the gitignore if you were developing an app locally.
Postman are now included some tools to check initial values for common formats of known authentication like Google, Microsoft. But this is just a value add, and doesn’t remove the personal responsibility of using the tool in the way it was designed.
If Postman had to make everything fool proof, then it would mean a lot of extra governance\steps to do things, and this would just make the app far more complex.
Please note: I’m not advocating in relation to the change to the offline mode. I’m just explaining what Postman has detailed in relation to the security for the cloud hosted aspects. It’s a shared responsibility.
To add an extra part to @michaelderekjones excellent explanation - We do have Role Based Access Control features in Postman at the Professional and Enterprise tiers which restricts and prevents users or groups of users from performing certain actions within a Team account.
That’s all control by the admin or admins of the Team - Given your use case, it wouldn’t cover all of the points in regards to secret variables but it would give a greater level of access control, over the members of the team.
I do understand the recommendations in terms of CICD best practices.
I was curious if there’s a way to limit access to our Environment Variables within Postman itself for one-time triggers, instead of a whole Collection being run which is what teams usually do in their pipelines.
Thanks for the comprehensive explanation, @danny-dainton, @michaelderekjones. Will keep in mind.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.