To ensure these rules and security requirements were understood and correctly executed, we led multiple hands-on training sessions. These trainings also helped the team learn the new functionality of Postman Pro.

The roll-out process took just 3 weeks, including planning, pricing negotiation, and training.

Securing Postman Pro

It is important to ensure that secrets stay secret. Leaking passwords, authorization tokens, customer PII, or API keys can lead to a security nightmare. Postman provides mechanisms for saving secrets locally and referencing them in synced collections, endpoints, and scripts. However, YOU are responsible for doing that correctly.

Postman syncs (saves) all collections and endpoints to its servers. Any values that are hard coded into the endpoint configurations are also synced to their servers. This includes private collections, which can be viewed by checking the Postman Dashboard for your personal account.

To secure Postman Pro, we required engineers to remove ALL instances of hard coded environment secrets in shared and private Postman collections and move them to Postman Environments. We also required all employees to delete their published links to Postman collections, which you can see (and delete) in the dashboard view.

During Postman Pro security training sessions, we focused on a few major points to secure Postman Pro for the initial rollout;

Don’t leak secret information, environment variables, or documentation Do not share collections or documentation with public facing links

However, no amount of training can prevent accidental or careless leaks of environment secrets. For this reason, one of our engineers built an automated script which uses the Postman Pro API to identify all synced configurations with hard coded secrets located on Postman’s servers.

The script performs the following checks:

Downloads all private and shared collections and checks each property of each endpoint configuration against a collection of secrets provided to the script Checks each user’s profile for published links Checks all private and shared collections for published documentation

You can check out the script on Taylor Daugherty’s Github.

How BetterCloud Uses Postman Pro

We rely on Postman Pro primarily for collections, environments, and pre-request scripts. Each feature provides its own unique value to our organization.

Collections

Collections are a group of saved API requests. Within a collection, requests can be organized into folders.

Each team at BetterCloud owns at least one collection for each major feature. Within each collection, requests are organized by microservice. These collections are shared via Postman Pro. This provides structure and common organization, which makes locating and trying out endpoints easy. It also keeps all teams up to date with the latest endpoint contracts.

Environments

Environments are a group of key value pairs that are referenced while sending requests or running scripts. Multiple environments can be setup to represent different deployed and development environments. The pairs are scoped to a named environment but Postman also provides a global context for parameters that do not change across environments. Developers and testers use environments to “change” multiple parameters at the same time.

We store the following information in environments to support requests to local, non-production, and production servers.

Host names: http://localhost:8080 vs https://testenv.domain.com

http://localhost:8080 vs https://testenv.domain.com Identifiers: admin user ids, customer ids,

admin user ids, customer ids, Auth token: JWT, and OAuth tokens

JWT, and OAuth tokens Environment secrets: HMAC keys and API keys

Pre-request and Test Scripts

Pre-request scripts are javascript snippets that run before a request is sent. This allows you to do things like add generated headers (e.g. timestamps) or calculate and apply HMAC headers. Scripts have access to environment variables using `postman.getGlobalVariable(key)` or `postman.getEnvironmentVariable(key)`.

Engineers at BetterCloud use pre-request scripts to apply HMAC headers. Since timestamps are part of our HMAC hash, it allows Postman Pro to calculate and apply the hash, signature, and signed headers as request headers.

Test scripts and collection runners can provide a lot of value, making smoke tests stupid simple while also providing a group of example requests and responses.

We have plans to further evaluate test scripts in order to improve our automated test coverage.

Was it worth it?

In our journey to make BetterCloud, well, better; Postman Pro is a step in the right direction.

Documentation in spreadsheets and on whiteboards is a thing of the past. With Postman Pro, we’ve created a single source of truth for all API endpoints that’s shared across the organization. Parameters are now comprehensively outlined, and in addition, Postman Pro’s environment templates massively increased our team’s productivity. Lastly, and most importantly, secret keys instantly became more secure when they are not saved to 3rd party servers.

Postman Pro has positively affected many people at BetterCloud. Our engineers have seen increased velocity and more efficient inter-team communication. Testers and DevOps are now able to easily sync collections to ensure they have the latest endpoints and examples to support non-prod and production environments.

Amazingly, Postman Pro has made REST API exploration and demos so simple that non-technical people have started using it for data exploration and support debugging.

So was it worth it? Absolutely.

Looking for a new career opportunity? Join BetterCloud. We’re hiring.