Vault write identity/entity-alias not actually adding the alias

Vault
1

I am following https://learn.hashicorp.com/vault/identity-access-management/iam-identity, but it isn’t working.

I created an entity named jack-mckinney and a userpass user named jackmc.
According to that page, the output of vault write entity/alias should be two lines with the two IDs. But instead, I just get a terse success message:

$ USERPASS_ACCESSOR=$(vault auth list -format=json | jq -r '.["userpass/"].accessor')
$ vault write identity/entity-alias name=jackmc \
 canonical_id=${CANON_ID} \
 mount_accessor=${USERPASS_ACCESSOR}                                                                                            
Success! Data written to: identity/entity-alias
$

When I view the entry, there are no aliases:

$ vault read identity/entity/id/${CANON_ID}

Key                    Value
---                    -----
aliases                []
[...]
name                   jack-mckinney
namespace_id           root
policies               [default user]

And, indeed, the ‘user’ policy above that grants access via the template (copy/pasted from that link) isn’t granting:

$ vault login -method=userpass username=jackmc
[...]
$ vault token capabilities user-kv/data/jack-mckinney/foo
deny

What am I doing wrong?

2

Update: I was doing this on my QA server (i.e., not in “-dev” mode). I decided to do this on a “-dev” server from a script so that I could post the script. But… it worked.
It looks like this is working in “-dev” mode, but NOT working in prod mode.

3

The first place where there is a difference. If I run this against a “dev” mode server I see:

$ vault write identity/entity-alias name=jackmc canonical_id=$ENTITYID mount_accessor=$ACCESSOR                                                                                                                
Key             Value
---             -----
canonical_id    d4aed0ee-0dc7-e1a9-46f8-7717ed38ff30
id              6b4f0e1a-4a60-1215-6bc7-1f1e016963a2

The same command when running against a dev mode server gives:

$ vault write identity/entity-alias name=jackmc canonical_id=$ENTITYID mount_accessor=$ACCESSOR
Success! Data written to: identity/entity-alias
$

The very next command in the script is
$ vault read identity/entity/id/$ENTITYID

For prod, the aliases line shows “”. For Prod, it shows:

[map[canonical_id:d4aed0ee-0dc7-e1a9-46f8-7717ed38ff30 creation_time:2020-04-23T19:42:48.767372542Z id:6b4f0e1a-4a60-1215-6bc7-1f1e016963a2 last_update_time:2020-04-23T19:42:48.767372542Z merged_from_canonical_ids:<nil> metadata:<nil> mount_accessor:auth_userpass_8bd77b9f mount_path:auth/userpass/ mount_type:userpass name:jackmc]]

4

I wrote a script to reproduce this and set up clean -dev and non -dev servers, and it didn’t reproduce. But it still reproduces on my server.
Then comes the interesting part. If I create it with my entity and usernames (jack-mckinney and jackmc) it reproduces. If I use the ones from the tutorial (bob-smith and bob), it works.

It is almost like the bob-smith and bob usernames are coded into the vault binary so that this only works with those strings. WTF???

Look at the difference in output when I use the name from the Hashicorp tutorial and when I use my name:

$ vault write identity/entity name=bob-smith policies=user

Key        Value
---        -----
aliases    <nil>
id         5f1643e7-7ff8-9a00-5505-6be10c6c7674
name       bob-smith

$ vault write identity/entity name=jack-mckinney policies=user
Success! Data written to: identity/entity
$
5

OK, this was really bizarre. My script worked fine on -dev and on a prod-mode server that I set up to test. It also worked on my qa server for any new accounts I created, but not for the initial one that I created. That was the only case where I could reproduce it.
So, I blew away my qa vault and re-created it and it worked fine.
I have no idea why my account was in that state. But, all better now.

6

Experiencing something very similar on vault 1.8.3 backed by cassandra. Write claims it’s successful but cannot read the entity-alias through UI or through the CLI by requesting name read. I think we managed to get vault into a bad state through some dodgy scripting on our end…but I have no clue how to rectify the bad state.

7

If you are looking for help, please start a new topic of your own - “something similar” to a 2 year old topic just isn’t enough detail to engage with, by far.