manifoldco/torus-cli

Torus List Command

MattAWright opened this issue · 1 comments

MattAWright commented

One feature that users frequently request is the ability to quickly view all secrets within an organization and/or project. This is crucial information that users should be able to view conveniently.

Problem

Specifically, the problems we would like to solve include:

  • There is no single/easily readable list of all secrets stored within Torus and so this information is difficult to obtain.
  • It is difficult to find out who has access to those secrets and vice versa, ie. which secrets a user or team has access to.
  • It is difficult to understand/see the Torus project structure/hierarchy
  • It is hard or impossible to search for secrets (ie. show all PORTs)

Issues With Current Implementation

The current solutions, ie. torus ls addresses some of these issues either directly or indirectly but suffers from its own issues, including:

  • It performs unnecessary crypto in the background which slows it down.
  • It is confusing and difficult to read/understand, and the output style is clunky.
  • It is directly tied to the credential path. This means that instead of making the project structure obvious/readable, it requires the user to have an accurate mental model of the credential path already.

Proposed Solution

The solution proposed is to introduce a new command torus list. This command will list all secrets within a specified org/project in a style that makes the project structure apparent to the user. The user can pass any of several flags that will help filter out/narrow in on particular secrets. In general, this might look like:

torus list --org ORG --project PROJ [--environment ENV] [--service SERVICE] [--user USERNAME] [--team TEAMNAME] [--machine MACHINENAME] [--name SECRETNAME] [--verbose]

where

  • --org is a non-optional flag specifying the organization name
  • --project isa non-optional flag specifying the project name
  • --environment is an optional flag that filters out all secrets except those within the environment (or environment expression)
  • --service is an optional flag that filters out all secrets except those within the service (or service expression)
  • --user is an optional flag that presents the intersection of all secrets that both the specified user and currently logged-in user have access to. By default, torus list necessarily filters out all secrets except those which the currently logged-in user has access to.
  • --team is an optional flag that filters out all teams except the team specified.
  • --machine is an optional flag the filters out all teams except the machine teams specified.
  • --name is an optional flag that filters out all secrets except those with the specified name.
  • --verbose is an optional flag that causes the full credential path of each secret to be listed.

Example

$torus list -o matt -p matts-project -e dev-* -s api

/matt/matts-project
        /dev-matt
                /api
                        port
                        password
        /dev-ian
                /api
                        port
                        password

Notes

One issue not addressed by this approach is an easy way to discover all the teams and users that have access to a particular secret (effectively the inverse of the currently proposed torus list). A solution to this problem requires an entirely different output style and set of manipulations and is best addressed with a separate command, eg. torus inspect --secret.

ianlivingstone commented

Awesome, a few questions:

It performs unnecessary crypto in the background which slows it down.

This is mentioned as a problem, but I don't think there is a specific solution? One thought is to introduce a decrypt query parameter to the GET /credentials end point inside the daemon which would tell the daemon not to decrypt the secrets. Instead it'd just send an empty CredentialValue struct down to the CLI.

This could be done before or after this issue, but something we should tackle -- it'd make this command (and many others) super fast! Perhaps we should open another issue to track it?

--environment, --service flags

Can these be specified many times to narrow the search? Also can you pass wildcard flags? I'd assume specified many, just wanted to clarify.

--machine is an optional flag the filters out all teams except the machine teams specified.

Wouldn't this specify the machine name? not it's role? (e.g. --machine api-prod-1 vs. --role api-prod or --team api-prod)?

Example

I wonder if some coloration (something we can experiment once we have a prototype working command) would make it easier for a user to view?

One issue not addressed by this approach is an easy way to discover all the teams and users that have access to a particular secret (effectively the inverse of the currently proposed torus list). A solution to this problem requires an entirely different output style and set of manipulations and is best addressed with a separate command, eg. torus inspect --secret.

Perhaps we should open another issue for further/future discussion?