How can I create personal repository by LDAP user?

Hello, I am using vault integrated with LDAP ( Active Directory) using LDAP groups as repository. It´s working fine.

Now I want to create personal repository and grant access to respective user?

Example:

AD user = xxuser
secret´s KV repository = xxuser

I want to grant only xxuser to access kv xxuser.

Thanks

Hi,

We have this implemented through policy-templates. We created a set of policies (test them, to see if they fit your organisation/version):

# List the users OWN folders only
path "my-secrets/metadata/{{identity.entity.aliases.<LDAP_ACCESSOR>.name}}" {
  capabilities = ["list"]
}

# Full Access on your own path
path "my-secrets/data/{{identity.entity.aliases.<LDAP_ACCESSOR>.name}}/*" {
  capabilities = ["create", "read", "list", "update", "delete"]
}

# Delete any version
path "my-secrets/metadata/{{identity.entity.aliases.<LDAP_ACCESSOR>.name}}/*" {
  capabilities = ["read", "list", "delete"]
}

Much of the remaining information on groups can be found in Learn Module on identity and groups as well as combining the information on the template policies, Mount Bound Aliasses and trial and error redering the acl using /sys/internal/ui/resultant-acl - HTTP API | Vault | HashiCorp Developer ( on test instances ).

Hello @alain,

I was not able to make it work at my environment.
My AD integration is using this user Search filter: ({{.UserAttr}}={{.Username}})

Can you help me to make it work?

Steps:

  • login with root token;
  • created a new secret engine ( KV 2 ) named ricardo (my Active Directory username);
  • edited default policy and added: "

List the users OWN folders only

path “secrets/metadata/{{identity.entity.aliases.<LDAP_ACCESSOR>.name}}” {
capabilities = [“list”]
}

Full Access on your own path

path “secrets/data/{{identity.entity.aliases.<LDAP_ACCESSOR>.name}}/*” {
capabilities = [“create”, “read”, “list”, “update”, “delete”]
}

Delete any version

path “secrets/metadata/{{identity.entity.aliases.<LDAP_ACCESSOR>.name}}/*” {
capabilities = [“read”, “list”, “delete”]
}
"

I think you may have missed some of the readings. This is not LDAP, but using the userpass. First, enable userpass.

vault auth enable userpass

Then we can list it to see the Accessor:

vault auth list
Path         Type        Accessor                  Description
----         ----        --------                  -----------
token/       token       auth_token_3bdac925       token based credentials
userpass/    userpass    auth_userpass_4c49ed54    n/a

We can now create a policy template “own-secret” - I’m showing two scenarios:

vault policy write own-secret - <<EOF
path "{{identity.entity.aliases.auth_userpass_4c49ed54.name}}/*" {
  capabilities = ["create", "read", "update", "patch", "delete", "list"]
}
path "secret/data/{{identity.entity.aliases.auth_userpass_4c49ed54.name}}/*" {
  capabilities = ["create", "read", "update", "patch", "delete", "list"]
}
EOF

Now, if we create two users - they both have the own-secret policy :

vault write auth/userpass/users/alain password=alain policies=own-secret
vault write auth/userpass/users/ricardo password=ricardo policies=own-secret

As you did, we create two kv paths:

vault secrets enable -path=alain kv-v2
vault secrets enable -path=ricardo kv-v2

Now when you login as alain :

vault login -method=userpass username=alain
vault read -format=json sys/internal/ui/resultant-acl

...
    "glob_paths": {
      "alain/": {
        "capabilities": [
          "create",
          "delete",
          "list",
          "read",
          "update",
          "patch"
        ]
      },
...

And when you log in as ricardo:

vault login -method=userpass username=ricardo

...
      "ricardo/": {
        "capabilities": [
          "create",
          "delete",
          "list",
          "read",
          "update",
          "patch"
        ]
      },
...

Still as user ricardo:

root@934036e3b745:/workdir# vault kv put alain/test a=foo
Error making API request.

URL: GET http://vault:8200/v1/sys/internal/ui/mounts/alain/test
Code: 403. Errors:

* preflight capability check returned 403, please ensure client's policies grant access to path "alain/test/"
root@934036e3b745:/workdir# vault kv put ricardo/test a=foo
Key                Value
---                -----
created_time       2022-11-02T03:47:19.2550631Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1
root@934036e3b745:/workdir#

Links to the docs :

I hope this helps.

NOTE: I was using 1.9.9, there are some changes in 1.12 to create the secrets mounts. Also, the resultant-acl is just to show the actual acl that gets created. You will notice the two polcies in the listings, I only show one. This is the what the second policy path gives for the ricardo user:

      "secret/data/ricardo/": {
        "capabilities": [
          "create",
          "delete",
          "list",
          "read",
          "update",
          "patch"
        ]
      },