← Back to list

Zero-Touch Vault: Automating Identity Access Management with Postman

Today, perhaps more than ever, the risks and consequences of lacking an effective Identity and Access Management (IAM) strategy are…

Fj Gonzalez in Globant · 2026-07-09 14:11 · 0 claps · 10.2 min read
#hashicorp-vault #postman #postman-collections #ami #cloudops
Open on Medium ↗
Wiki topics: BIZ · Business Strategy

Zero-Touch Vault: Automating Identity Access Management with Postman

Image generated using IA openart.ai

Image generated using IA openart.ai

Today, perhaps more than ever, the risks and consequences of lacking an effective Identity and Access Management (IAM) strategy are significant and potentially damaging for organizations. This challenge becomes even more critical in environments where proper controls and automation are absent, leading to increased exposure to human error, security vulnerabilities, data obsolescence, limited oversight, a lack of traceability, and regulatory non-compliance.

If this situation sounds familiar and you’re considering taking action before an incident occurs, this article will guide you through a hands-on introductory lab.

We’ll use HashiCorp Vault as a centralized source of truth to securely manage sensitive data and handle both human and machine identities that interact with it. With Postman, we’ll automate several common operational tasks in this domain, providing a practical starting point that you can later extend to build a robust IAM strategy.

Prerequisites

Before proceeding, ensure you have the following:

  • A running Vault instance (or cluster). The version used in this article is 1.21.4
  • The Vault root token.
  • The Vault CLI is installed.
  • Postman installed. The version used in this article is 12.3.3
  • Basic familiarity with IAM and automation concepts.

Part 1 — Overview and initial HashiCorp Vault Configuration

Image generated using IA ChatGPT

Image generated using IA ChatGPT

Before diving into the implementation, let’s briefly review the key concepts and terminology used throughout this article.

  • HashiCorp Vault: It is a cloud-agnostic secrets management platform that serves as a centralized system for storing, accessing, and auditing sensitive data (secrets). It also supports dynamic credentials, encryption-as-a-service, key management, secure secret distribution, and more.
  • Postman: an API client and automation tool for interacting with RESTful services. In this context, it will be used to programmatically interact with Vault’s HTTP API, allowing us to automate configuration and operational workflows.
  • Identity and Access Management (IAM): In a nutshell, a framework of policies, processes, and technologies used to verify identity (authentication) and control access (authorization). It plays a critical role in enforcing security, managing identity lifecycles, and ensuring appropriate access to resources.
  • Human Identities: Refer to individual users who interact directly with Vault. These identities typically authenticate via methods such as LDAP, GitHub, or OIDC, and require credential-based authentication and session management.
  • Machine Identities: Also known as non-human identities, these represent automated entities such as applications, microservices, or CI/CD pipelines. They require secure, programmatic access to Vault without relying on interactive or human authentication mechanisms.
  • AppRole: Vault’s authentication method designed specifically for machine identities. It uses a combination of a Role ID and a Secret ID to authenticate and generate a token, enabling secure, non-interactive access to Vault resources.
  • Secrets Engine: A secrets engine is a core component of Vault responsible for storing, generating, or managing sensitive data. Depending on the engine type, Vault can either securely persist secrets or generate them dynamically on demand.
  • Auth Method: In Vault, the Auth Method is the component responsible for verifying the identity of a user (human) or application (machine) and mapping that identity to a set of permissions.
  • Least Privilege Access: This principle ensures that identities are granted only the minimum set of permissions required to perform a specific task, for the shortest duration necessary, and within a clearly defined scope.

Hands-on: Automating Vault with Postman Collections

When accessing HashiCorp Vault, you will see in the Secrets engines section that the “cubbyhole” (token private) and “secret” (key/value) are enabled by default. These are enough for this lab, since we will work with the “secret” engine to establish a centralized source of truth, allowing us to securely store and manage sensitive information.

Secrets Engine’s main page in Vault

Secrets Engine’s main page in Vault

But on the Authentication Methods side, by default, only the token method is enabled, so we will enable the userpass method for human identities and the approle method for machine identities.

NOTE: You can skip this configuration if you already have them enabled in your Vault instance.

Run the following commands from your terminal to enable them:

% export VAULT_ADDR='http://10.10.1.0:8200'
% export VAULT_TOKEN='your-root-token' 
% vault auth enable userpass
Success! Enabled userpass auth method at: userpass/
% vault auth enable approle
Success! Enabled approle auth method at: approle/
% vault auth list
Path         Type        Accessor                  Description                Version
----         ----        --------                  -----------                -------
approle/     approle     auth_approle_e4457ab8     n/a                        n/a
token/       token       auth_token_9a8106c7       token based credentials    n/a
userpass/    userpass    auth_userpass_eb611e84    n/a                        n/a

This is how Vault should look after the different authentication methods in Authentication Methods are enabled:

Authentication Methods main page in Vault

Authentication Methods main page in Vault

Part 2 — Postman Collection for Human Identities

Image generated using IA ChatGPT

Image generated using IA ChatGPT

What is a Postman Collection?

A Postman Collection is an organized set of HTTP requests grouped within Postman, designed to consume, test, and document APIs in a structured and reusable way.

Each collection can include:

  • HTTP Method requests ( GET, POST, PUT, DELETE, etc.)
  • Environment variables
  • Headers
  • Request bodies (typically in JSON format)
  • Authentication scripts
  • Automated tests and validations
  • Technical documentation

Collections enable users and teams to define standardized actions and automate repeatable workflows while improving efficiency and strengthening security.

Create an Environment to store variables

We will start creating an environment, primarily to securely store the resulting request data (tokens) in variables. In addition, this will facilitate automation for us and provide safe conditions for teamwork and collaboration.

To create the environment, follow these steps:

Open Postman and go to the upper-right corner and click on “create environment”:

Environment variables in Postman — “Create environment”

Environment variables in Postman — “Create environment”

Use a descriptive name:

Environment’s variables in Postman — “Add descriptive name”

Environment’s variables in Postman — “Add descriptive name”

Finally, create the following variables with empty or mock values inside:

Environment variables in Postman — “Creating variables.”

Environment variables in Postman — “Creating variables.”

NOTE: We will also be working with “collection-level” variables within each collection, where we, as administrators or users, provide input data to HashiCorp Vault. They should not be confused with these “environment” variables, which capture and store data returned in Vault responses (such as authentication tokens).

Collection Userpass Management — Human Identities

Intended audience: Administrators.

Main purpose: Automating user creation within the userpass authentication method.

The workflow for this collection enables the creation of users in Vault, along with their associated policies and paths. Additionally, we’ve included a validation step to test credentials and instructions for deleting configurations if needed.

Create a new Collection named “Vault — 1 Userpass Management” and go to the Variables section to add the following variables and fill them out with the appropriate data, for example:

VAULT_ADDR: [http://vault.my.domain:8200](http://vault.my.domain:8200)

VAULT_TOKEN: ********************

USERNAME: alice

PASSWORD: ********************

(*) Make sure you are using the recently created environment.

Collection’s variables in Postman

Collection’s variables in Postman

Instructions to create a new request:

The Postman settings will be displayed in a table format. This way, you can easily see where to put the configurations in the corresponding fields. Example:

Configuration items for a new request in Postman

Configuration items for a new request in Postman

Continue creating the following requests inside the collection:

Collection Userpass Management — Create User Request

Request “1. Create User”

Request “1. Create User”

Collection Userpass Management — Create Policy Request

Request “2. Create Policy”

Request “2. Create Policy”

Collection Userpass Management — Validate Policy

Request “3. Validate Policy”

Request “3. Validate Policy”

Collection Userpass Management — Initialize User Path Request

Request “4. Initialize User Path”

Request “4. Initialize User Path”

Collection Userpass Management — Validation User Request

Request “5. Validation User”

Request “5. Validation User”

Collection Userpass Management — Login User Request

Request “Login user credentials”

Request “Login user credentials”

Collection Userpass Management — Delete User Path Request

Request “Delete User Path”

Request “Delete User Path”

Collection Userpass Management — Delete Policy Request

Request “Delete Policy”

Request “Delete Policy”

Collection Userpass Management — Delete User Request

Request “Delete User”

Request “Delete User”

After creating multiple users, this is how they, their policies, and their paths appear in the Vault UI:

Users

Users created in the “Userpass” Authentication Method in Vault

Users created in the “Userpass” Authentication Method in Vault

Policies

ACL Policies created in Vault

ACL Policies created in Vault

Policy content

Content of a user’s policy in Vault

Content of a user’s policy in Vault

Paths

Secret’s paths in a secret engine in the Vault

Secret’s paths in a secret engine in the Vault

Part 3 — Postman Collection for Secrets Management

Image generated using IA ChatGPT

Image generated using IA ChatGPT

Collection Secrets Management

Intended audience: Administrators and end users.

Main purpose: Focuses on managing secrets using the token generated when a user logs into Vault. The token is captured and stored in the USER_TOKEN environment variable, which will be used in subsequent Postman requests.

Scenario:

Assume you are Alice, and you want to start doing the best practices of storing credentials in Vault, let’s say the Payroll system credentials.

At this point, you already have valid Vault credentials and an exclusive path accessible only to you, as stipulated by policy.

Create a new Collection named “Vault — 2 Secrets Management” and go to the Variables section to add the following variables and fill them out with the appropriate data, for example:

VAULT_ADDR: [http://vault.my.domain:8200](http://vault.my.domain:8200)

USERNAME: alice

PASSWORD: *****************

SECRET_NAME: ClearTax

SECRET_PATH: {{USERNAME}}//{{SECRET_NAME}}

Collection’s variables in Postman

Collection’s variables in Postman

Continue creating the following requests inside the collection:

Collection Secrets Management — Login User Request

Request “Login user credentials”

Request “Login user credentials”

Using the USER_TOKEN obtained after the login user request and stored in an environment variable, you can securely write and retrieve your credentials from Vault with the following requests:

Collection Secrets Management — Create Secret Request

Request “Create Secret”

Request “Create Secret”

Collection Secrets Management — Read Secret Request

Request “Read Secret”

Request “Read Secret”

Collection Secrets Management — List Secrets Request

Request “List Secrets”

Request “List Secrets”

Collection Secrets Management — Delete Secret Request

Request “Delete Secrets”

Request “Delete Secrets”

After creating the secret, this is how it looks in the Vault UI:

Key/Value data for a secret stored in Vault

Key/Value data for a secret stored in Vault

Part 4 — Postman Collection for Machine Identities and Conclusions

Image generated using IA ChatGPT

Image generated using IA ChatGPT

Collection AppRole — Machine Identities

Intended audience: Administrators.

Main purpose: Introducing AppRole to enable secure, programmatic access for machine identities.

Scenario:

Now that Alice has her credentials securely stored in Vault, she needs to configure the software ClearTax (an internal tax processing system) to retrieve the appropriate credentials from her Vault path to perform tax-related operations. Since this needs to be programmatic access, her username/password won’t work, and an Approle comes into play.

Remember that an AppRole consists of two parts: a *role_id and a `secret_id`*.

When authenticated, these generate a token with a controlled Time-To-Live of 24 hours (customizable), which ClearTax will be used to retrieve the required secrets. The generated token is stored in an environment variable named APPROLE_TOKEN. This token will then be used for secure, programmatic interaction with Vault’s secrets.

Create a new Collection named “Vault — 3 AppRole Management” and go to the Variables section to add the following variables and fill them out with the appropriate data, for example:

VAULT_ADDR: [http://vault.my.domain:8200](http://vault.my.domain:8200)

VAULT_TOKEN: *****************

USERNAME: alice

SECRET_NAME: ClearTax

ROLE_NAME: {{USER_NAME}}-approle

POLICY_NAME: {{ROLE_NAME}}-policy

OWNERS: FinOps, Treasury

Collection’s variables in Postman

Collection’s variables in Postman

Continue creating the following requests inside the collection:

You can customize the generated token; in this example, it is for 24 hours. The AppRole itself is configured with a lifespan of one year (customizable). After this period, it must be renewed to continue generating tokens.

Collection AppRole — Create AppRole Request

Request “1. Create Approle”

Request “1. Create Approle”

Although *Approles can be configured with full capabilities (`create*,update`, *delete*), it is better to restrict them to read-only access, since they will only consume data.

Collection AppRole — Create Policy Request

Request “2. Create Policy”

Request “2. Create Policy”

The *role_idcreated will be stored in an environment variable named `ROLE_ID`* that will be used to log in with the Approle

Collection AppRole — Get Role ID Request

Request “Get Role ID”

Request “Get Role ID”

The *secret_id created will be stored in an environment variable named `SECRET_ID`* that will be used to log in with the Approle

Collection AppRole — Generate Secret ID Request

Request “Generate Secret ID”

Request “Generate Secret ID”

Collection AppRole — Login AppRole Request

Request “Login AppRole (Token)”

Request “Login AppRole (Token)”

Using the APPROLE_TOKEN obtained after Approle login and stored in an environment variable, you can securely retrieve the credentials from Vault with the following request:

Collection AppRole — Read Secret Request

Request “Read Secret (“ClearTax”)”

Request “Read Secret (“ClearTax”)”

The previous request demonstrated that the APPROLE_TOKEN generated upon login can be used to retrieve information from Vault. This token must be configured in the “ClearTax” software to manage tax payments.

Conclusions

In this article, we examined how to build a practical foundation for automating identity and access management with HashiCorp Vault. By using its HTTP API and integrating with tools like Postman, we demonstrated how to perform common operational tasks consistently and repeatedly.

We discussed both human and machine identity workflows, emphasizing how various authentication methods address different access patterns while maintaining a cohesive security model.

Beyond the technical steps, the main point is the move toward a zero-touch approach, in which identity provisioning, access control, and secret management are automated, auditable, and scalable. This not only minimizes human error but also enhances operational efficiency and overall security.

Real-world deployments require additional considerations such as secret rotation strategies, audit logging, integration with CI/CD pipelines, and centralized identity providers. The next step is to incorporate these workflows into your delivery pipelines and progress toward fully automated, policy-driven security operations.

References


메타데이터
post_id
370f3615bae4
slug
zero-touch-vault-automating-identity-access-management-with-postman-370f3615bae4
url
https://medium.com/globant/zero-touch-vault-automating-identity-access-management-with-postman-370f3615bae4
canonical_url
https://medium.com/globant/zero-touch-vault-automating-identity-access-management-with-postman-370f3615bae4
author_url
https://medium.com/@fj.gonzalez
status
ok
fetched_at
2026-07-10 13:01:02