Auth/token/lookup-self does not work

Vault
1

Hi,

Am I going mad??

$ vault token create -ttl 15m -policy test
Key                  Value
---                  -----
token                s.YuMTkrFzVtr6A5by5jLwJIYS
token_accessor       SbTuBuAyeeUThADDfkxRqgSi
token_duration       15
token_renewable      true
token_policies       ["default" "test"]
identity_policies    []
policies             ["default" "test"]

$ vault token capabilities s.YuMTkrFzVtr6A5by5jLwJIYS auth/token/lookup-self
read

$ export VAULT_TOKEN=s.YuMTkrFzVtr6A5by5jLwJIYS
$ vault kv get auth/token/lookup-self
Error making API request.

URL: GET http://localhost:8200/v1/sys/internal/ui/mounts/auth/token/lookup-self
Code: 403. Errors:

* preflight capability check returned 403, please ensure client's policies grant access to path "auth/token/lookup-self/"

Thanks,

Ian

2

I think you want to use the command vault read auth/token/lookup-self instead.

1 Like
3

Ha, doh. Yep, that works.

But… it does beg the question why vault kv get auth/token/lookup-self works with a root token, but not a non-root one??

Thanks!

Ian

4

The default policy contains this as the allowed path:

path "auth/token/lookup-self" {
    capabilities = ["read"]
}

The permission denied message cites a different path (not sure why).

You could probably add the following to the default policy to get it to work for any token:

path "sys/internal/ui/mounts/auth/token/lookup-self" {
    capabilities = ["read"]
}

EDIT: Nope - that doesn’t work either. I’m also curious why that doesn’t work now.

5

“But… it does beg the question why vault kv get auth/token/lookup-self works with a root token, but not a non-root one??”

Can’t it be because the root token always everything? :sunglasses:

6

@jeffsanicola I managed to figure it out! It’s:

path "auth/token/lookup-self" {
    capabilities = ["update"]
}
7

auth/token/lookup-self is an unusual endpoint which performs the same operation on read or update.

read is the normal way to use it. I assume update exists for some obscure compatibility reason - or maybe no reason at all.

Adding the update capability in a policy is not needed for the operations in this topic.

Here I am running the command that started this topic (even though it’s technically incorrect, since it’s using KV tooling to talk to a non-KV) and it works, with nothing more than the built-in default default policy:

$ vault kv get auth/token/lookup-self
========== Data ==========
Key                 Value
---                 -----
accessor            WJol77jSzTCGICZa1zDdAEAT
creation_time       1671559389
creation_ttl        768h
display_name        userpass-basic
entity_id           782db8a9-759c-1ff4-6c98-4cd1d96863ad
expire_time         2023-01-21T18:03:09.20504172Z
explicit_max_ttl    0s
id                  hvs.xxxxxx
issue_time          2022-12-20T18:03:09.205058554Z
meta                map[username:basic]
num_uses            0
orphan              true
path                auth/userpass/login/basic
policies            [default]
renewable           true
ttl                 767h59m55s
type                service

As to why it didn’t work in 2021? No idea, perhaps a bug has been fixed in the intervening time, or perhaps something unknown went wrong in the testing.

sys/internal/ui/mounts/ is a special API that does not require conventional policy to call. Instead it enforces its own permission checking internally, and will only return data for mounts you have some access to.

It is used by vault kv ... to probe whether the path is a KV v2, or not.