Namespaces and global auth methods

I want to use namespaces in a Vault as a Service deployment model where each namespace is for isolated and dedicated use of a particular area within an organisation.

The organisation has some business wide IAM systems and want to enable things like LDAP and Kubernetes authentication methods that can be used by any of the business areas using Vault.

After reading through the Vault website the options seem to be to:

  1. declare a new auth method in each namespace (using the same auth method configuration e.g. the same LDAP servers & username) that is for exclusive use by that namespace
  2. declare common global auth methods in a parent namespace and then define policies in that parent namespace that specify which permissions a successful login allows in the child namespaces e.g. to read secrets in the child namespace k/v store

Option 1 requires duplication of auth methods in each namespace and means any update to the backend IAM system e.g. updating the LDAP access URL and/or service account credentials (for Vault to authenticate with) will require updates in every defined namespace where this auth method is declared. This may result in large numbers of duplicate auth methods associated with large numbers of namespaces. It does however allow full autonomy for the child namespace administrators who can declare their own policies and thus determine for example what secrets may be accessed from a login with that method. There is no need to rely on some other team in the organisation performing policy administration to enable access to secrets in their namespace.

Option 2 means (common) auth backends are declared just once and can be used by all business areas/child namespaces. A separate team e.g. a security team would declare and administer the common global auth methods and any updates would be picked up by all child namespaces (no need to make multiple updates as with option 1). This would however require the team e.g. the security team with admin permissions on the parent namespace to declare the policies that allow access into the child namespaces for the auth methods. This means each business area has a dependency on the security team performing policy work for them before they can start using that auth method.

Is there a solution that combines option 1 and 2 so that auth methods are declared just once but allowing the child namespace admins to be fully autonomous without having to rely on some other team performing policy updates at the parent namespace level?

Hi there!

I think you’re pretty much on-point with the pros and cons of the two options for auth methods namespaces are in play.

For option number 2, you can delegate namespace admins (who log in from the parent namespace) to administer permissions for users in the parent namespace who log into the child namespace by using identity groups. This guide goes through a similar scenario on how this can be set up and exercised (steps 3 and 5), but in essence your namespace admins need to have policies to manipulate groups in the child namespace (creation, aliasing, etc.), and add parent-level users as group members. When a group member logs in, they will inherit the policies from that group (in addition to any top level policies were granted/denied into the child namespace).

1 Like

Hi there,
I had read through that a couple of times and my understanding is that every entity that will login to Vault needs to be pre-created individually in the parent namespace, which may be quite a large number. It’s not clear to me yet from that guide or this one whether it is possible to set up permissions such that the child namespace admins can control group membership thereby providing more autonomy for them and less admin burden for the parent namespace level - I will look into this further.
Thank you for your helpful reply which has helped me know I havent missed anything and given food for thought around the identity and groups.

The member entity ID is globally unique and thus a group from the child namespace can designate a member on the parent to be part of the group. It is possible to set up permissions such that child namespace admins can control group membership as long as they have policies to do so. For instance, this command on the guide can be done by a namespace admin as long as it has the ACL policy to manipulate identity/ paths in the child namespace, education/training.

vault write -namespace=education/training identity/group \
        name="Training Admin" policies="training-admin" \
        member_entity_ids=$(cat entity_id.txt)

There is some setup involved, but depending on the auth method used, you may be able to use external groups to avoid setting up individual entities.

1 Like

@fastenough, did you try the approach of global auth method for Kubernetes auth method? I was able to wrap my head around @calvn’s suggestion on using external groups for auth methods such as LDAP/Github (user based auth) but could not quite map it to Kubernetes auth method.

I might be missing something while understanding this -

“There is some setup involved, but depending on the auth method used, you may be able to use external groups to avoid setting up individual entities.”

I tried creating the Kube auth method on the parent namespace (root in my case), creating an entity for it and tried to create an alias for it in the child namespace. I however got this error -

# creating an alias in the child namespace pointing to the kube auth method in the root namespace
vault write identity/entity-alias name="kubernetes-child-namespace" \
        canonical_id="ac26d62f-b8a3-92ca-e6v6-86b47ccd4ad2" \
        mount_accessor="auth_kubernetes_168ff82b"

Error writing data to identity/entity-alias: Error making API request.

URL: PUT https://vault.cdl.es.oneadp.com/v1/identity/entity-alias
Code: 403. Errors:

* matching mount is in a different namespace than request

The reason I was trying to create the alias was to allow the injected vault agent sidecars to be able to authenticate using the <child/namespace>/v1/auth/<kubernetes-auth-path>/login API