---
layout: docs
page_title: Configure cross namespace access
description: >-
Set up cross namespace access in Vault without using hierarchical relationships.
---
> [!IMPORTANT]
> **Documentation Update:** Product documentation, which were located in this repository under `/website`, are now located in [`hashicorp/web-unified-docs`](https://github.com/hashicorp/web-unified-docs), colocated with all other product documentation. Contributions to this content should be done in the `web-unified-docs` repo, and not this one. Changes made to `/website` content in this repo will not be reflected on the developer.hashicorp.com website.
# Configure cross namespace access in Vault
Using the `sys/config/group_policy_application` endpoint, you can enable secrets sharing
across multiple independent namespaces.
Historically, any policies attached to an [identity group](/vault/docs/concepts/identity#identity-groups) would only apply when the
Vault token authorizing a request was created in the same namespace as that
group, or a descendent namespace.
This endpoint reduces the operational overhead by relaxing this restriction.
When the mode is set to the default, `within_namespace_hierarchy`, the
historical behaviour is maintained. When set to `any`, group policies apply to
all members of a group, regardless of what namespace the request token came
from.
## Prerequisites
- Vault Enterprise 1.13 or later
- Authentication method configured
## Enable secrets sharing
1. Verify the current setting.
```shell-session
$ vault read sys/config/group-policy-application
Key Value
--- -----
group_policy_application_mode within_namespace_hierarchy
```
`within_namespace_hierarchy` is the default setting.
1. Change the `group_policy_application_mode` setting to `any`.
```shell-session
$ vault write sys/config/group-policy-application \
group_policy_application_mode="any"
```
```plaintext
Success! Data written to: sys/config/group-policy-application
```
Policies can now be applied, and secrets shared, across namespaces without a
hierarchical relationship.
## Example auth method configuration
Cross namespace access can be used with all auth methods for both machine and
human based authentication. Examples of each are provided for reference.
1. Create and run a script to configure the Kubernetes auth method, and two
namespaces.
```plaintext
# Create new namespaces - they are peers
vault namespace create us-west-org
vault namespace create us-east-org
#--------------------------
# us-west-org namespace
#--------------------------
VAULT_NAMESPACE=us-west-org vault auth enable kubernetes
VAULT_NAMESPACE=us-west-org vault write auth/kubernetes/config out_of=scope
VAULT_NAMESPACE=us-west-org vault write auth/kubernetes/role/cross-namespace-demo bound_service_account_names="mega-app" bound_service_account_namespaces="client-nicecorp" alias_name_source="serviceaccount_name"
# Create an entity
VAULT_NAMESPACE=us-west-org vault auth list -format=json | jq -r '.["kubernetes/"].accessor' > accessor.txt
VAULT_NAMESPACE=us-west-org vault write -format=json identity/entity name="entity-for-mega-app" | jq -r ".data.id" > entity_id.txt
VAULT_NAMESPACE=us-west-org vault write identity/entity-alias name="client-nicecorp/mega-app" canonical_id=$(cat entity_id.txt) mount_accessor=$(cat accessor.txt)
#--------------------------
# us-east-org namespace
#--------------------------
VAULT_NAMESPACE=us-east-org vault secrets enable -path="kv-marketing" kv-v2
VAULT_NAMESPACE=us-east-org vault kv put kv-marketing/campaign start_date="March 1, 2023" end_date="March 31, 2023" prise="Certification voucher" quantity="100"
# Create a policy to allow read access to kv-marketing
VAULT_NAMESPACE=us-east-org vault policy write marketing-read-only -< token.txt
```
1. Read a secret in the `us-east-org` namespace using the Vault token from
`us-west-org`.
```shell-session
$ VAULT_NAMESPACE=us-east-org VAULT_TOKEN=$(cat token.txt) vault kv get kv-marketing/campaign
```
1. Create and run a script to configure the userpass auth method, and two
Vault namespaces.
```plaintext
# Create new namespaces - they are peer
vault namespace create us-west-org
vault namespace create us-east-org
#--------------------------
# us-west-org namespace
#--------------------------
VAULT_NAMESPACE=us-west-org vault secrets enable -path="kv-customer-info" kv-v2
VAULT_NAMESPACE=us-west-org vault kv put kv-customer-info/customer-001 name="Example LLC" contact_email="admin@example.com"
# Create a policy to allow read access to kv-marketing
VAULT_NAMESPACE=us-west-org vault policy write customer-info-read-only -< accessor.txt
VAULT_NAMESPACE=us-west-org vault write -format=json identity/entity name="TAM" | jq -r ".data.id" > entity_id.txt
VAULT_NAMESPACE=us-west-org vault write identity/entity-alias name="tam-user" canonical_id=$(cat entity_id.txt) mount_accessor=$(cat accessor.txt)
#--------------------------
# us-east-org namespace
#--------------------------
VAULT_NAMESPACE=us-east-org vault secrets enable -path="kv-marketing" kv-v2
VAULT_NAMESPACE=us-east-org vault kv put kv-marketing/campaign start_date="March 1, 2023" end_date="March 31, 2023" prise="Certification voucher" quantity="100"
# Create a policy to allow read access to kv-marketing
VAULT_NAMESPACE=us-east-org vault policy write marketing-read-only -< token.txt
```
1. Read a secret in the `us-east-org` namespace using the Vault token from
`us-west-org`.
```shell-session
$ VAULT_NAMESPACE=us-east-org VAULT_TOKEN=$(cat token.txt) \
vault kv get kv-marketing/campaign
```
## API
- [/sys/config/group-policy-application](/vault/api-docs/system/config-group-policy-application)
## Tutorial
- [Secrets management across namespaces without hierarchical relationship](/vault/tutorials/enterprise/namespaces-secrets-sharing)