Identity dupe resolution guide first draft #29308
Conversation
github-actions
bot
added
the
hashicorp-contributed-pr
📄 Content ChecksUpdated: Tue, 07 Jan 2025 17:04:30 GMT Found 3 error(s)
|
| Position | Description | Rule |
|---|---|---|
137:5-138:117 |
Unexpected fully-qualified link to developer.hashicorp.com: https://developer.hashicorp.com/vault/api-docs/secret/identity/entity-alias#delete-entity-alias-by-id. Replace with a relative path internal to Developer. Possibly: /vault/api-docs/secret/identity/entity-alias#delete-entity-alias-by-id. |
ensure-valid-link-format |
233:12-234:22 |
Unexpected folder-relative link found: . Ensure this link is an absolute Developer path. | ensure-valid-link-format |
content/docs/upgrading/upgrade-to-1.19.x.mdx
| Position | Description | Rule |
|---|---|---|
58:55-58:75 |
Unexpected folder-relative link found: . Ensure this link is an absolute Developer path. | ensure-valid-link-format |
|
CI Results: |
|
|
||
| # Vault identity duplicate resolution guide | ||
|
|
||
| Some users may have duplicate identity resources (entities, aliases, groups) in |
There was a problem hiding this comment.
How about linking the word "identity" to the introductory identity docs page, so that people who come to this page from the 1.19 upgrade guide and aren't very familiar with entities/aliases/groups can do some initial reading to remind themselves what these things are first before they continue.
|
|
||
| ``` | ||
| [WARN] identity: 2 different-case entity alias duplicates found (potential security risk) | ||
| [WARN] identity: entity-alias "alias-case" with mount accessor "auth_userpass_34aca7ec" duplicates 1 others: id=df3568a4-3b65-4104-9481-1129ecbed72f canonical_id=5f013d99-a6c7-9a00-6ad5-4ad724b14f60 force_deduplication="would merge into entity 7da76b0d-fe9b-a125-3362-2a8ff055dcf8" |
There was a problem hiding this comment.
Just a question: Feel free to take this offline as it's not related to this PR and probably more to my overall noobery, but I'm just curious what a canonical ID is vs the regular ID. In this example log line I was first trying to find the corresponding entity 7da7 and didn't realize it was the canonical_id I was supposed to be looking at, not the id.
Is there a way for users to query identity resources by canonical ID to inspect them, and see "aha, they're right, it's merged"? Or can you only query by id? I'm just curious from a UX perspective.
There was a problem hiding this comment.
Ah yeah it's a detail that's maybe only clear if you know the API a bit - canonical_id is what we call the field of an alias that stores the ID of the entity it's aliasing. If you think in SQL then it's like aliases JOIN entities ON aliases.canonical_id = entities.id. So when we output a line about an alias dupe canonical_id means "the entity this alias points to". See https://developer.hashicorp.com/vault/api-docs/secret/identity/entity-alias#canonical_id
| the cluster that reports them is a Performance Replication secondary, you will | ||
| need to perform any resolution steps necessary against that cluster and not the | ||
| Primary. | ||
|
|
There was a problem hiding this comment.
What happens to same-case entity alias duplicates? I don't see a section for that. Is it so simple that it can be covered right away before jumping into all these different-case scenarios? Or is there no such thing?
There was a problem hiding this comment.
Yeah I left it out because it's nuanced: basically those are already auto-merged. I've alluded to the alias merging in a few places but was kinda trying to avoid spelling out the complicated history of that here for brevity. I guess it's a natural question though so I'll see if I can work in a simple statement to indicate that they won't been found without going into the details.
There was a problem hiding this comment.
I think in Aarah's restructure this isn't exactly dealt with but is less of an issue as it's more split up into specific trouble shooting guides. It still seems cumbersome to find a place to explain why not other types so I think her structure is sufficient to guide the user through without the extra background.
| or group by name. Simply changing the reference to use the new name is the | ||
| simplest resolution. | ||
|
|
||
| ### Activating the `force-identity-deduplication` flag |
There was a problem hiding this comment.
I know it was said somewhere way up above, but once you write this part I think it might be good to make sure there's another warning here that this is a one-time thing, so they should review the resolution information for their relevant duplicate types above before activating the flag.
Description
First draft of the Idenity duplicate resolution docs. The features described are not all merged yet but this document is so important we want to start getting feedback on it ASAP.
TODO only if you're a HashiCorp employee
backport/label that matches the desired release branch. Note that in the CE repo, the latest release branch will look likebackport/x.x.x, but older release branches will bebackport/ent/x.x.x+ent.of a public function, even if that change is in a CE file, double check that
applying the patch for this PR to the ENT repo and running tests doesn't
break any tests. Sometimes ENT only tests rely on public functions in CE
files.
in the PR description, commit message, or branch name.
description. Also, make sure the changelog is in this PR, not in your ENT PR.