Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhancement: lookup by fqn command #345

Open
jakedoublev opened this issue Aug 28, 2024 · 0 comments
Open

Enhancement: lookup by fqn command #345

jakedoublev opened this issue Aug 28, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@jakedoublev
Copy link
Contributor

jakedoublev commented Aug 28, 2024

Background

Currently in the platform there are 4 types of Fully Qualified Names (FQNs) that correspond to objects within OpenTDF Platform policy:

  1. attribute namespaces: https://<namespace>
  2. attribute definitions: https://<namespace>/attr/<attribute definition name>
  3. attribute values: https://<namespace>/attr/<attribute definition name>/value/<value>
  4. resource mapping groups: https://<namespace>/resm/<group name>

Two things are possible and maybe even likely:

  1. the number of objects that can be fully qualified with a namespace will grow (registered KASes, various mappings)
  2. the structure of the FQN itself may change

The otdfctl CLI has done a great job simplifying the CRUD of policy (attributes/mappings) for platform administrators. However, as the data is truly a graph structure, there is a known desire to understand policy objects by their names rather than their IDs.

There are already some service-to-service RPCs that exist within the platform to contextualize various FQNd policy objects without use of UUIDs:

  1. GetAttributesByValueFQNs (with lookup for a value-less attribute FQN already existing within)
  2. ListResourceMappingsByGroupFQNs

The behavior of these existing RPCs is different from our normal GET/LIST behaviors because it is known that requests to these RPCs seek great depth of context around the policy object being queried. They are service-first RPCs rather than admin-CRUD-first RPCs. That said, we can expose them in the CLI via a lookup functionality. This would be durable to any future FQN extensions or changes and serve the admin/PEP developer need to understand everything relevant to a policy object.

Acceptance Criteria

  1. otdfctl policy lookup [fqn] takes any supported FQN as an argument
  2. the CLI breaks down the FQN argument into its known supported kind
  3. the CLI calls the relevant Policy FQN-driven-read RPC to provide the entire context (all mappings, all grants, etc) to the policy object
  4. the CLI outputs the JSON response
@jakedoublev jakedoublev added the enhancement New feature or request label Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant