Token roles don't respect 'allowed_entity_aliases' parameter

[kauedg]

Describe the bug
When a token role is created using the allowed_entity_aliases parameter it is still possible to create a token using the role when no entity alias is passed.

To Reproduce

1. Create a dev server with the needed resources:

$ vault server -dev &
$ export VAULT_ADDR='http://127.0.0.1:8200'
$ vault login [root token]

# Create a KV with a secret
$ vault secrets enable -path=TEST -version=1 kv
$ vault write TEST/somesecret password=passw0rd

# Create a policy that allows reading the above secret and the role, restricting the aliases allowed to use it
$ echo '{ "path": [ { "TEST/*": { "capabilities": ["read", "list"] } } ] }' | vault policy write read_secret -
$ vault write auth/token/roles/read_test_role allowed_policies=read_secret allowed_entity_aliases=privileged_alias

# Enable userpass, create a user and a policy that allows it to create tokens using the role
$ vault auth enable userpass
$ echo '{ "path": [ { "auth/token/create/read_test_role": { "capabilities": ["update"] } } ] }' | vault policy write someuser_policy -
$ vault write auth/userpass/users/someuser password='12344321' token_policies=someuser_policy

2. Check that the user can't read the secret and can't create a token using his alias

$ vault login -method=userpass username=someuser password=12344321
$ vault read TEST/somesecret
Error reading TEST/somesecret: Error making API request.

URL: GET http://127.0.0.1:8200/v1/TEST/somesecret
Code: 403. Errors:

* 1 error occurred:
        * permission denied

$ export VAULT_TOKEN=$(vault token create -role=read_test_role -entity-alias=someuser -field token)
Error creating token: Error making API request.

URL: POST http://127.0.0.1:8200/v1/auth/token/create/read_test_role
Code: 400. Errors:

* invalid 'entity_alias' value

$ unset VAULT_TOKEN

3. But the user is able to get a token and read the secret, without passing the entity_alias parameter or with a valid alias:

$ export VAULT_TOKEN=$(vault token create -role=read_test_role -field token)
$ vault read TEST/somesecret
Key                 Value
---                 -----
refresh_interval    768h
password            passw0rd

$ unset VAULT_TOKEN
$ export VAULT_TOKEN=$(vault token create -role=read_test_role -entity-alias=privileged_alias -field token)
$ vault read TEST/somesecret
Key                 Value
---                 -----
refresh_interval    768h
password            passw0rd

$ unset VAULT_TOKEN

Expected behavior
The documentation states that:

allowed_entity_aliases (string: "", or list: []) - String or JSON list of allowed entity aliases. If set, specifies the entity aliases which are allowed to be used during token generation. This field supports globbing. Note that allowed_entity_aliases is not case sensitive.

If a list of allowed users is set, there's no point in allowing anyone else to generate a token using the role. The API should refuse generating the token when entity-alias is not passed/empty.

Environment:

• Vault Server Version (retrieve with vault status): 1.9.0
• Vault CLI Version (retrieve with vault version): Vault v1.9.0
• Server Operating System/Architecture: Ubuntu 20.04.3 LTS / amd64

Vault server configuration file(s): none, dev server

Additional context
None

[ryowright]

I'd like to take a look at this.

[ryowright]

So I've been able to successfully add a proper error response if no 'entity_alias' field is supplied.

The current error message reads: "no 'entity_alias' value supplied".

ryowright@Ryos-MacBook-Pro bin % export VAULT_TOKEN=$(./vault token create -role=read_test_role -field token)
Error creating token: Error making API request.

URL: POST http://127.0.0.1:8200/v1/auth/token/create/read_test_role
Code: 400. Errors:

* no 'entity_alias' value supplied

[ryowright]

@kauedg Are there any additional changes you'd like added or should I open a pull request for this?

[kauedg]

Go ahead

[ncabatoff]

Hi @kauedg,

Can you help me understand what problem this is causing? Changing this is going to break backwards compatibility, so we'd need a pretty good reason.

[kauedg]

@ncabatoff I believe this problem could be treated as a security risk. An alias could receive inadequate permissions only from knowing the higher-permission role name.

Besides, if the allowed_entity_aliases field isn't checked against the alias asking for a token role, the field is doing nothing at all.

[kauedg]

@ncabatoff any insights on this issue?

If a token role was supposed to be protected from unauthorized token generation, based on an entity alias whitelist, and an unauthorized alias is able to create a token from this role, it is clear to me it's a case of unauthorized access.

I believe that the points I made are a good reason to patch the endpoint's behaviour.

[ncabatoff]

I think you are envisioning a different use case than was intended for allowed_entity_aliases. We could add a require_entity_alias bool param to roles for your use case.

[kauedg]

I think you are envisioning a different use case than was intended for allowed_entity_aliases. We could add a require_entity_alias bool param to roles for your use case.

Which use case would require an allowed entity list but allowing any alias to request tokens, at the same time? I believe that the field's name implies that other aliases shouldn't be allowed to request tokens, so the new field wouldn't even be required.

If there's such use case then I think the require_entity_alias should be created.

[ncabatoff]

The field was added in #6267, and the fact that they made it optional suggests to me that they weren't thinking about it the same way you are. Either way, we can't change this retroactively without the risk of breaking things for someone, so the new behaviour you're looking for must be opted-in to via a new field.

[kauedg]

The field was added in #6267, and the fact that they made it optional suggests to me that they weren't thinking about it the same way you are. Either way, we can't change this retroactively without the risk of breaking things for someone, so the new behaviour you're looking for must be opted-in to via a new field.

So, if I understood correctly, allowed_entity_aliases is an additional list of aliases that are able to create a role token from this role, beyond the entities that already have permissions (by means of a policy) to do so?

[ncabatoff]

I don't think so. allowed_entity_aliases specifies which entities can be bound to tokens created with that role. It doesn't constrain token creation, it grants permission to extend the privileges of the created token by granting it the permissions associated with the entity tied to be to the specified alias. Another use case is for billing: with Vault Enterprise, you're billed based on how many "clients" you have, so by using tying the token to an entity you can ensure the "client" associated with that token will be that entity. This is less important in recent versions, since we treat all tokens with the same set of policies in a given namespace as a single "client".

If you want to restrict access to the token role to specific entities, you should use identity policies to grant access to the role endpoint.

[kauedg]

Here we go, now I got it. Maybe the field's documentation could use some rephrasing.

The endpoint has fields that are related to the endpoint (like allowed_policies) while others are related to the created token (like orphan). They have different definitions on to which case they apply. Maybe the allowed_entity_aliases description could be changed to something more alike to those about the token.