Introduction
Namespaces are segregated environments that serve as "Vaults within Vaults" for the purpose of providing data isolation within organisations. One way to configure the authentication mechanism when using multiple namespaces with an external identity provider (e.g LDAP) is to just configure it at the root namespace level. This facilitates the administration of the authentication method but necessitates management of all namespace level policies at the root level.
Use case
There is a way around the restriction described in the introduction above and makes it possible to administer policies within namespaces : Use vault external groups and map them to vault internal groups formed within the namespace. Here are two benefits:
- Administer policies within namespaces for each namespace even when auth method is only configured in root namespace.
- End users have the ability to log in as the root user in a single namespace and then move to a different namespace based on the policies.
Procedure
- Note that vault token to set this up should have required privileges to run these administrative tasks in vault; such as identity group creation, enabling auth engine and writing policies.
Below are the set of commands to be run in vault for creating an external group in root namespace, creating an internal group in any namespace and mapping the two groups. In this sample set, the LDAP auth method is utilised, but it can also be used with other authentication methods (depending on an external identity provider).
1. Fetch the accessor_id of auth method (auth method is already configured with name ldap) :
vault auth list -format=json | jq -r '.["ldap/"].accessor' > accessor_ldap.txt
2. Create an external group and fetch the group_id of the created group :
vault write -format=json identity/group name="test-external-group" type="external" | jq -r ".data.id" > group_id.txt
3. Create a group-alias and map this to the group created in earlier step :
vault write identity/group-alias name="VAULT-USERS" mount_accessor=$(cat accessor_ldap.txt) canonical_id="$(cat group_id.txt)"
Please note that group-alias name VAULT-USERS is exactly same as a LDAP group named VAULT-USERS in LDAP backend. For successful mapping, this needs to be the same. Below is the format of expected outcome in CLI :
Key Value
--- -----
canonical_id b4a09c95-8967-9383-0a7b-a4362afba068
id 3014d024-68a4-87e4-af89-243ba5fec058
4. Export the namespace in environment variable VAULT_NAMESPACE, as remaining steps are to be executed at namespace level :
export VAULT_NAMESPACE=test-ns
5. Create a policy file for allowing access to kv-v2 secret engine named test-engine
cat test-policy.hcl
path "test-engine/*"
{
capabilities = ["read", "list", "update", "create", "delete"]
}
path "sys/capabilities-self"
{
capabilities = ["read", "list", "update", "create", "delete"]
}
6. Write the policy in vault with the capabilities defined in previous step :
vault policy write test-ns-access test-policy.hcl
Success! Uploaded policy: test-ns-access
7. Enable a secret engine named test-engine . Also, create some sample secrets in the secret engine for testing the implementation later.
vault secrets enable -path=test-engine kv-v2
Success! Enabled the kv-v2 secrets engine at: test-engine-2/
8. Create a internal group in the namespace, assign the policy we wrote in previous steps, and add external group as member of this internal group:
vault write identity/group name="test-internal-group" policies="test-ns-access" member_group_ids=$(cat group_id.txt)
Below is the format of expected outcome in CLI :
Key Value
--- -----
id 4f1cda9d-f8dc-64d7-e5c1-1c75e93c0563
name test-internal-group
This implementation can then be tested with user logon after this step. Anyone logged in as a member of the LDAP group VAULT-USERS will have the option to switch to the test-ns namespace and access secrets in the test-engine. Please be aware that all of the aforementioned actions are also available through the vault UI.
Related Articles