Vault
Configure cross namespace access
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 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
Verify the current setting.
$ vault read sys/config/group-policy-application Key Value --- ----- group_policy_application_mode within_namespace_hierarchywithin_namespace_hierarchyis the default setting.Change the
group_policy_application_modesetting toany.$ vault write sys/config/group-policy-application \ group_policy_application_mode="any"Success! Data written to: sys/config/group-policy-applicationPolicies 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.
Create and run a script to configure the Kubernetes auth method, and two namespaces.
# 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 -<<EOF path "kv-marketing/data/campaign" { capabilities = ["read"] } EOF # Create a group VAULT_NAMESPACE=us-east-org vault write -format=json identity/group name="campaign-admin" policies="marketing-read-only" member_entity_ids=$(cat entity_id.txt)Authenticate to the
us-west-orgVault namespace with a valid JWT.$ VAULT_NAMESPACE=us-west-org vault write -format=json auth/kubernetes/login role=cross-namespace-demo jwt=$(cat jwt.txt) | jq -r .auth.client_token > token.txtRead a secret in the
us-east-orgnamespace using the Vault token fromus-west-org.$ VAULT_NAMESPACE=us-east-org VAULT_TOKEN=$(cat token.txt) vault kv get kv-marketing/campaign