IBM Support

Managing Vault Namespace Manipulation Using Sentinel Policies

Troubleshooting


Problem

Introduction

HashiCorp Vault offers advanced governance through Sentinel policies, which allow administrators to enforce complex rules that go beyond traditional Vault ACL policies. In this guide, we’ll explore using Sentinel to restrict namespace manipulation, a task that is often challenging with standard ACLs due to the hierarchical nature of namespaces.

Introduction

Namespaces in Vault modify request paths. For example:

  • A token lookup in the root namespace uses the path: auth/token/lookup.
  • The same request in a nested namespace (ns1) becomes: ns1/auth/token/lookup.

Vault ACL policies support path wildcards like * or +, but they do not currently handle recursive or nested namespace paths. Sentinel policies solve this limitation by enabling regex matching and other advanced rules.

This guide demonstrates how to configure Sentinel to prevent namespace creation, deletion, or updates by all users except a specific super-admin.

 

Prerequisite: 

 

Scenario

The objective is to:

  • Allow general administrative privileges to users (admin policy).
  • Restrict all users from modifying namespaces except for a designated super-admin (bob).

 

Setup Steps

Note: this example will use Docker along with a Vault Enterprise license.  As a prerequisite your license should be exported into an environment variable named VAULT_LICENSE.

 

1. Start a Vault Instance

sudo docker run \
--cap-add=IPC_LOCK \
-e VAULT_DEV_LISTEN_ADDRESS='0.0.0.0:8200' \
-e VAULT_ADDR='http://0.0.0.0:8200' \
-e VAULT_DEV_ROOT_TOKEN_ID=root \
-e VAULT_LICENSE=$(echo $VAULT_LICENSE) \
-p 8200:8200 \
--name vault \
--detach \
hashicorp/vault-enterprise

export VAULT_ADDR=http://localhost:8200
sleep 2
vault login root

 

2. Define Vault Users and Policies

  1. Create an Admin Policy:
vault policy write admin - << EOF
path "*" {
capabilities = ["create", "read", "update", "delete", "list", "sudo"]
}
EOF

 

2. Enable Userpass Authentication:

vault auth enable userpass
vault write auth/userpass/users/bob password=root token_policies=admin
vault write auth/userpass/users/jill password=root token_policies=admin

 

3. Link Bob to an Entity for Sentinel Context:

ENTITY_ID=$(vault write -format=json identity/entity name="bob" policies="admin" | jq -r '.data.id')
USERPASS_ACCESSOR=$(vault auth list -format=json | jq -r '.["userpass/"].accessor')

vault write identity/entity-alias name="bob" \
canonical_id=$ENTITY_ID \
mount_accessor=$USERPASS_ACCESSOR

 

3. Create a Sentinel Policy

  1. Policy Definition:
cat <<'EOF' > blockns.sentinel
precond = rule {
request.path matches "^(.*)sys\\/namespaces\\/(.*)$" and request.operation in ["create", "update", "delete"]
}

prevent_namespaces = rule {
identity.entity.name is "bob"
}

main = rule when precond {
prevent_namespaces
}
EOF

2. Enable the Sentinel Policy:

POLICY=$(base64 blockns.sentinel)
vault write sys/policies/egp/blockns \
policy="${POLICY}" \
paths="*" \
enforcement_level="hard-mandatory"

 

4. Unit Testing with Sentinel

  1. Prepare Test Files:
mkdir -p test/blockns

# Test for allowed namespace manipulation by 'bob'
cat <<'EOF' > test/blockns/allow-ns.json
{
"global": {
"request": {
"path": "sys/namespaces/test",
"operation": "create"
},
"identity": {
"entity": {
"name": "bob"
}
}
},
"test": {
"precond": true,
"prevent_namespaces": true,
"main": true
}
}
EOF

# Test for blocking namespace manipulation by 'jill'
cat <<'EOF' > test/blockns/block-ns.json
{
"global": {
"request": {
"path": "sys/namespaces/test",
"operation": "create"
},
"identity": {
"entity": {
"name": "jill"
}
}
},
"test": {
"precond": true,
"prevent_namespaces": false,
"main": false
}
}
EOF

 

2. Run Sentinel Tests:

sentinel test

 

5. Field Testing

  1. Login and Test Namespace Manipulation:
vault login -method=userpass username=bob password=root
vault namespace create ns1 # Allowed

vault login -method=userpass username=jill password=root
vault namespace create ns2 # Blocked

 

Key Takeaways

  • Flexibility: Sentinel provides regex and conditional logic not available in Vault ACL policies.
  • Scalability: This policy manages all namespace paths, including deeply nested ones.
  • Governance: Enforcement levels (e.g., hard-mandatory) ensure strict compliance.

This workflow demonstrates Sentinel's power to extend Vault's functionality, ensuring secure and fine-grained control over namespace manipulation.

 

References:

Getting Started with Sentinel Policies:

https://developer.hashicorp.com/sentinel/tutorials/get-started

 

Enforce access control with Sentinel policies

https://developer.hashicorp.com/vault/tutorials/policies/sentinel

 

 

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB77","label":"Automation Platform"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSLC9Y2","label":"IBM Vault Self-Managed"},"ARM Category":[{"code":"a8mgJ0000000E4iQAE","label":"Vault-\u003ECore"}],"ARM Case Number":"","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"1.14.10;1.14.11;1.14.12;1.14.13;1.14.4;1.14.5;1.14.6;1.14.7;1.14.8;1.14.9;1.15.0;1.15.1;1.15.10;1.15.11;1.15.12;1.15.13;1.15.14;1.15.15;1.15.16;1.15.2;1.15.3;1.15.4;1.15.5;1.15.6;1.15.7;1.15.8;1.15.9;1.16.0;1.16.1;1.16.10;1.16.11;1.16.12;1.16.13;1.16.14;1.16.15;1.16.16;1.16.17;1.16.18;1.16.19;1.16.2;1.16.20;1.16.21;1.16.22;1.16.23;1.16.24;1.16.25;1.16.26;1.16.27;1.16.28;1.16.29;1.16.3;1.16.30;1.16.31;1.16.4;1.16.5;1.16.6;1.16.7;1.16.8;1.16.9;1.17.0;1.17.1;1.17.10;1.17.11;1.17.12;1.17.13;1.17.14;1.17.15;1.17.16;1.17.17;1.17.18;1.17.2;1.17.3;1.17.4;1.17.5;1.17.6;1.17.7;1.17.8;1.17.9;1.18.0;1.18.1;1.18.10;1.18.11;1.18.12;1.18.13;1.18.14;1.18.15;1.18.2;1.18.3;1.18.4;1.18.5;1.18.6;1.18.7;1.18.8;1.18.9;1.19.0;1.19.1;1.19.10;1.19.11;1.19.12;1.19.13;1.19.14;1.19.15;1.19.16;1.19.17;1.19.2;1.19.3;1.19.4;1.19.5;1.19.6;1.19.7;1.19.8;1.19.9;1.20.0;1.20.1;1.20.10;1.20.11;1.20.2;1.20.3;1.20.4;1.20.5;1.20.6;1.20.7;1.20.8;1.20.9;1.21.0;1.21.1;1.21.2;1.21.3;1.21.4;1.21.5;1.21.6;2.0.0;2.0.1;4.2.0-5.4.0"}]

Historical Number

9016703678739

Document Information

Modified date:
09 June 2026

UID

ibm17264853