HashiCorp Vault

Configuring the Veza integration for HashiCorp Vault Server

Early Access: Please contact our support team to enable this integration for your Veza platform.

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 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"]
}

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

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

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:

1. In Veza, go to the Integrations page.

2. Click Add Integration and pick HashiCorp Vault as the type of integration to add. Click Next under the list of integrations.

3. 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.