UI: LDAP Hierarchical roles

[hellobontempo]

Description

This PR adds hierarchical role navigation to the UI for LDAP roles which was added to the CLI in 1.17 (Hierarchical Paths). These changes were nontrivial due to the API and GUI design, which I'll outline below for consideration during future list views and navigation with path style resources.

Screen.Recording.2024-11-04.at.12.10.31.PM.mov

Listing hierarchical roles in LDAP returns only top-level items. For example, this ldap engine has the dynamic role paths: admin/role1, admin/nested/role2, my-role. A LIST request has to be made at each level to glean this. Roles are also dependent on :type and so the same must be done for static roles with static-role in the path instead of role.

⚡ ⇒ vault list ldap/role 
Keys
----
admin/ 
my-role

⚡ ⇒ vault list ldap/role/admin
Keys
----
role1
nested/

⚡ ⇒ vault list ldap/role/admin/nested 
Keys
----
role2

Some API endpoints, like this namespaces one, list all of the paths Note: this is a sys/internal/ui endpoint

⇒ curl \
   --header "X-Vault-Token: <token>" \
   --request GET \
http://127.0.0.1:8200/v1/sys/internal/ui/namespaces | jq
--------
{
 "data": {
   "keys": [
     "admin/",
     "admin/child/"
   ]
 }
}

Considerations

Existing list patterns

KV v2 has a similar pattern because secret paths can be nested (i.e. nested/path/to/secret). The route file defines separate routes, list is for listing secrets in the engine and list-directory is for secret paths that end in a forward slash. The list route inherits from list-directory.js because much of the routing logic is the same. In LDAP, I chose to create a base route model class to share the lazyPaginatedQuery method but maintain separate model hooks.

The major difference here is in LDAP navigating through hierarchical roles does not update the filter input and pageFilter maps one to one to the filter input. I opted for this to separate concerns: url paths and navigation is unrelated to filtering the list results which is the responsibility of query params.

On the top, navigating into the admin/ subdirectory changes the URL and breadcrumbs, but the filter is not updated unless a user wants to filter within that directory. In KV v2, clicking into a subdirectory adds that path to the filter, even though the URL is not updated with the corresponding pageFilter

Note: locally I changed the config to only list 2 items to test pagination (instead of the default of 100)

In both engines, filtering updates the query params, but in KV v2 only the suffix is included (which makes sense because we're inside that secret path, however it's confusing UX because the filter input does not match the URL query params)

Aside - client-side pagination in KV v2 appears to be broken when pageFilter exists, which seems to be an additional argument for separate route models

Pagination

The original implementation of LDAP roles uses the same model ldap/role for both dynamic and static roles. Typically, we want model schemas to map closely to the API params (see Models docs for our expected ember data model patterns). Following this pattern, ldap/role should have been a base class with any shared params (like name) and for defining adapter/serializer methods as those are the same. Static and dynamic role models would inherit this class and then define type-specific fields and params (see #28829 for what this would look like).
Abandoned because the list view displays both static and dynamic roles and our client-side pagination service relies on these being the same model.

💡 Future improvement/suggestion

We should remove our reliance on the ember-data store for client-side pagination and instead manage that request and caching as a javascript class. This way we can request whatever data we want and store it, instead of relying on 1 ember data model per pagination view.

SearchSelect

The API structure of LDAP roles makes components like SearchSelect unusable out of the box as it requires a LIST request is made at each level. For the first iteration of the hierarchical roles implementation, we decided to filter out pathed roles, so only top-level roles are available for quickly generating credentials here:

💡 Future imrpovement/suggestion

When designing "quick action" cards for path-supported items we could build a component similar to KvSuggestionInput (code) which makes a request at each level. Or outfit the existing component to be more general and accept any resource to list and query.

TODO only if you're a HashiCorp employee

• Backport Labels: If this PR is in the ENT repo and needs to be backported, backport
  to N, N-1, and N-2, using the backport/ent/x.x.x+ent labels. If this PR is in the CE repo, you should only backport to N, using the backport/x.x.x label, not the enterprise labels.
  • If this fixes a critical security vulnerability or severity 1 bug, it will also need to be backported to the current LTS versions of Vault. To ensure this, use all available enterprise labels.
• ENT Breakage: If this PR either 1) removes a public function OR 2) changes the signature
  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.
• Jira: If this change has an associated Jira, it's referenced either
  in the PR description, commit message, or branch name.
• RFC: If this change has an associated RFC, please link it in the description.
• ENT PR: If this change has an associated ENT PR, please link it in the
  description. Also, make sure the changelog is in this PR, not in your ENT PR.

[hellobontempo]

we can't use name as the primaryKey because static and dynamic roles can technically have the same name

[hellobontempo]

this is because ember data likes IDs and Vault doesn't return them. Pulled this into a helper here so it can be reused in tests and mirage so this didn't have to be updated in multiple places

[hellobontempo]

since we're no longer extending the NamedPathAdapter, had to add these methods to manually return ID info

[github-actions]

CI Results:
All Go tests succeeded! ✅

[hellobontempo]

Added _ to denote private methods that are only used within this adapter to clearly distinguish them from builtin adapter methods

[github-actions]

Build Results:
All builds succeeded! ✅

[Monkeychip]

:)

[hellobontempo]

[Monkeychip]

Really nice work. That PR description is what dreams are made of. One question, nothing blocking.

[Monkeychip]

🤔 Does this need fn wrapped around, so it's clear you're passing role.name into this.isHierarchical()

[hellobontempo]

This is actually a template helper so it has slightly different syntax 😄 Docs

[Monkeychip]

TIL, thank you!

[Monkeychip]

Nice 🧼 :)

[Monkeychip]

good call out.

[hellobontempo]

Since these are locally type definitions, I find simpler names to be easier to read and follow. WhenTheyGetReallyLong it's hard to map them back to their definition in my opinion 😅

[hellobontempo]

Forgot to post but ✅ enterprise passed