1 of 1

HashiCorp Vault

Configuring the Veza integration for HashiCorp Vault Server

Overview

HashiCorp Vault enables organizations to securely store and manage secrets, according to policies. Secrets can be API keys, passwords, or certificates, or other data objects where access is tightly regulated. The Veza integration connects to a self-managed or cloud-hosted Vault cluster to discover users, namespaces, and resources, including:

Principals

HashiCorp Vault Alias

Resources:

HashiCorp Vault Namespace
HashiCorp Vault System Backend
HashiCorp Vault Auth Method
HashiCorp Vault Auth Method Subresource
HashiCorp Vault Secrets Engine
HashiCorp Vault Secrets Engine Subresource
HashiCorp Vault Policy

The integration can show:

Vault users with access to Vault secrets, and the path of authentication for those users.
Identities with access via passwords, app roles, AWS IAM, and Okta
All secrets and the users authorized for those secrets. See notes and supported entities for more details.

Configuring HashiCorp Vault

Veza connects to HashiCorp Vault by assuming an application role in your environment. You will need to create an role AppRole that will be used for extraction. Then, attach it to a policy granting the required permissions for extraction.

You can do this by connecting to your server and running vault commands:

Create a policy for the Veza role

Create the policy to attach to the Veza AppRole. Paste the following policy into a text file and save it veza-policy.hcl.

Veza extraction policy for HashiCorp Vault

path "/sys/namespaces" {
  capabilities = ["list"]
}

# entities

path "/identity/entity/id" {
  capabilities = ["list"]
}

path "/identity/entity/id/*" {
  capabilities = ["read"]
}

# groups

path "/identity/group/id" {
  capabilities = ["list"]
}

path "/identity/group/id/*" {
  capabilities = ["read"]
}

# auth methods

path "/sys/auth" {
  capabilities = ["read"]
}

path "/auth/+/role" {
  capabilities = ["list"]
}

path "/auth/+/role/*" {
  capabilities = ["read"]
}

path "/auth/+/roles" {
  capabilities = ["list"]
}

path "/auth/+/roles/*" {
  capabilities = ["read"]
}

path "/auth/+/users" {
  capabilities = ["list"]
}

path "/auth/+/users/*" {
  capabilities = ["read"]
}

path "/auth/+/groups" {
  capabilities = ["list"]
}

path "/auth/+/groups/*" {
  capabilities = ["read"]
}

# policies

path "/sys/policies/acl" {
  capabilities = ["list"]
}

path "/sys/policies/acl/*" {
  capabilities = ["read"]
}

# secrets engines

path "/sys/mounts" {
  capabilities = ["read"]
}

path "/+/metadata/*" { # kv2
  capabilities = ["list", "read"]
}

path "/+/roles" { # aws, azure
  capabilities = ["list"]
}

path "/+/roles/*" { # aws, azure
  capabilities = ["read"]
}

path "/+/rolesets" { # gcp
  capabilities = ["list"]
}

path "/+/rolesets/*" { # gcp
  capabilities = ["read"]
}

path "/+/static-accounts" { # gcp
  capabilities = ["list"]
}

path "/+/impersonated-accounts" { # gcp
  capabilities = ["list"]
}

Namespaces: If the policy is not defined for all namespaces on the cluster, extraction will fail. For each namespace, copy and edit each path block to define the same capabilities for all namespaces.

For example, for namespaces namespace-1 and namspace-1/namespace-2, duplicate the /sys/namespaces block to include:

path "/sys/namespaces" {
  capabilities = ["list"]
}

path "/namespace-1/sys/namespaces" {
  capabilities = ["list"]
}

path "/namespace-1/namespace-2/sys/namespaces" {
  capabilities = ["list"]
}

Do the same for all path blocks in the policy.

For a few namespaces, you can duplicate the policy in a text editor, and prefix the namespace to each path. For many namespaces, this should be done programmatically.

To get all namespaces in your Vault Server, use the command vault namespace list.

Add the policy to Vault, adjusting the name and path of the saved policy as needed:

vault policy write veza-extraction-policy path/to/veza-policy.hcl

Create an Application Role

Enable AppRole authentication and create the role:

vault auth enable approle

The response should be: Success! Enabled approle auth method at: approle/

Create the AppRole, and attach the policy you created:

vault write auth/approle/role/veza-extraction-role token_policies=veza-extraction-policy

The response will include the path to the app role: Success! Data written to: auth/approle/role/veza-extraction-role

Get the role ID and secret ID (sensitive):

vault read /auth/approle/role/veza-extraction-role/role-id

This returns the role_id, e.g. 10d51ce2-16bd-444b-4330-8fdcebfeda98

Get the secret ID:

vault write -f /auth/approle/role/veza-extraction-role/secret-id

Copy the secret_id, e.g. 16f03071-3ea6-2505-7bcc-153683766133.

Configuring HashiCorp Vault on the Veza Platform

To enable the integration:

In Veza, go to the Integrations page.
Click Add Integration and pick HashiCorp Vault as the type of integration to add. Click Next under the list of integrations.
Enter the required information and Save the configuration

Field

Notes

Insight Point

Choose whether to use the default data plane or a deployed Insight Point.

Cluster Id

ID of the cluster to connect to.

Cluster URL

URL of the cluster to connect to.

Auth Role ID

Vault role_id

Auth Secret ID

Vaule role secret_id

Identity Mappings

If your users can log into Vault with single sign-on, you will need to specify this relationship in a Custom Identity Mapping. For example, you can connect Okta Users to matching HashiCorp Aliases by adding a mapping configuration on the Okta integration. Pick HashiCorp Vault as the destination data source, using Alias Unique ID as the mapping property.

Notes and Supported Entities

HashiCorp Vault Cluster

Represents a top-level HashiCorp Vault Cluster. A Vault cluster is a set of Vault servers that share the same data storage backend, clustered for high availability and scaling.

HashiCorp Vault Namespace

Namespaces in Vault provide a way to partition resources and delegate management of those resources.

The root namespace is named admin. Namespaces can be nested.

HashiCorp Vault Group

Groups can be nested and can have a policy attached. Groups are a way to organize and manage entities (such as users or machines) in Vault.

Group memberships defined in one namespace referencing an entity from another namespace are not supported.

HashiCorp Vault Alias

Aliases represent principals that can access Vault resources. These are identities that can be used for authentication and authorization purposes in Vault.

HashiCorp Vault System Backend

Represents the API used to perform system actions such as creating namespaces. The system backend is a built-in secrets engine in Vault that allows management of system-level functionality.

HashiCorp Vault Auth Method

Authentication methods in Vault are the components used to authenticate clients and map them to internal entities. Veza currently supports vault authentication methods:

AppRole
AWS
Google Cloud Platform
Microsoft Azure
Okta
Token
Userpass

Contact our support team if your organization uses an alternative auth method.

HashiCorp Vault Auth Method Subresource

Can have a policy attached. Auth method subresources are specific configurations or resources within an authentication method, such as roles or bindings.

HashiCorp Vault Secrets Engine

Secrets engines in Vault are the components that store and manage secrets and other sensitive data. Veza currently supports the following secrets engines:

Key/Value Store (v2)
AWS
Microsoft Azure
GCP

HashiCorp Vault Secrets Engine Subresource

Alternatively called secrets. Some resources are not as sensitive, such as roles generated dynamically. Secrets engine subresources are specific configurations or resources within a secrets engine, such as key-value pairs or roles.

HashiCorp Vault Policy

Policy consists of statements that can allow or deny access to resources. Statements consist of a path (can include wildcards) and capabilities. Longer prefix paths take precedence over shorter ones. Policies in Vault are used to govern the access permissions of entities to various resources.

Entities in Vault can have a policy attached.

Namespaces

Namespaces are path-based and can be nested. Parent namespaces can define policies related to child namespaces. Namespaces provide a way to partition resources and allow delegated management of those resources in Vault.

Effective Permissions and Cross-Service Connections

Veza generates effective permissions between principals (HashiCorp Vault Alias) and resources (Namespaces, System Backend, Auth Method, Auth Method Subresource, Secrets Engine, Secrets Engine Subresource, Policy). Veza also shows connections between Vault namespaces, Vault namespace and cluster, Vault namespace and IdPs, and Vault namespace and existing integrations.

Limitations

Two Vault authorization concepts are not supported at present:

Templated Policies A policy may contain a set of variables. For instance, take the following policy clause:
```
path "secret/data/{{identity.entity.id}}/*" {
capabilities = ["create", "update", "patch", "read", "delete"]
}
```
This allows each user access to a user-specific area. Veza doesn't currently resolve these templates to show access to secrets.
External Namespace Group Memberships
Group memberships can be defined across different namespaces, independent of their hierarchy. An entity defined in one namespace can be referenced in a group in another namespace. Veza does not currently fetch policies across namespaces.