feat(cli): add trivy auth

[knqyf263]

Description

We have seen several use cases where people want to use Trivy in environments withoug container runtimes such as Docker. This PR adds trivy auth login and trivy auth logout to replace docker login and docker logout.

$ cat ~/my_password.txt | trivy auth login --username foo --password-stdin ghcr.io
$ trivy image ghcr.io/your/private_image
$ trivy auth logout ghcr.io

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[DmitriyLewen]

@knqyf263
left comments.
Take a loot, when you have time.

[DmitriyLewen]

LGTM

[knqyf263]

@itaysk I'll merge this PR, but we can fix the command name anytime you find a better one.

[itaysk]

feel free to merge, but I do think we'll need to change it.
I'll continue the discussion here (even if the PR is merged) since there's no issue/discussion.

[knqyf263]

@itaysk You can open a discussion if you want. Since I didn't think we needed a discussion on this topic, and it was easy to implement, I didn't create an issue, but I'm open to discussion.

[itaysk]

I'll try to summarize my feedback into 3 points:

1 - main login command should be reserved for main api login

when we say trivy auth login it's not very clear what the purpose of this login is for. docker login, gh auth login, snyk auth, aws sso login and every other CLI tool with a login command will sign me into the main service that the CLI is representing, and allow me to interact with the service via the CLI. So as a normal user might expect that trivy auth login will allow me to sign into the trivy service - maybe this is trivy server mode, maybe this is aqua, maybe this is the future version of trivy server/aqua, but either way, I'm not sure it's expected that the main login command will authenticate me to an arbitrary container registry.

2 - registry login is not the only kind of auth we support

Flows based on container registry:

1. pulling image to scan
2. pulling a trivy asset from registry (except vex-db): trivy-db/trivy-java-db/trivy-checks
3. installing wasm modules from registry

Flows not based on container registry:

1. scanning other targets: all are authenticated ourside of trivy
   1. private repos - GitHub/GitLab token in env vars
   2. k8s clusters - kubeconfig
   3. AMI - AWS SDK env vars
   4. TF modules - TF SDK env vars
2. vex repository: HTTP auth, or implementation specific auth
3. trivy client/server mode: dedicated --token flag

3 - several registry authentication options

If I understand correctly, this command (or docker login) will cover all of the registry based flows listed abobe.
It appears that if the artifact is hosted in AWS/Azure/GCP registry, docker login (or this command) will not suffice, and cloud-specific authentication will be required (please correct me if wrong). Also, we currently aupport dedicated --username/--password flags for basic authentication registries.

[knqyf263]

docker login (or this command) will not suffice, and cloud-specific authentication will be required (please correct me if wrong)

It is required to obtain a password for docker login or trivy auth login, like aws ecr get-login-password | docker login --username AWS --password-stdin xxxxxxxxxxx.dkr.ecr.us-east-1.amazonaws.com.

trivy auth registry login appears to help some of your feedback. What do you think?

[simar7]

my reservation was that when we say trivy auth login it's not very clear what the purpose of this login is for.

@itaysk that's an interesting point and to be honest I do agree, it sounds like trivy requires a login to use it's functionality.

trivy auth registry login appears to help some of your feedback. What do you think?

If we're not planning to support any other credentials in the future, trivy registry login might be shorter. But on the other hand, if we do want to support future creds (maybe telemetry?), then I agree keeping trivy auth <subcommand> <action> is probably better.

[itaysk]

trivy auth registry login appears to help some of your feedback. What do you think?

yes it does

excuse me for thinking out loud for a bit:
we have a number of other similar commands for managing connection to external registries: trivy module, trivy plugin and trivy vex. Today these commands don't mange authentication to the respective registries (maybe in the future they will?) but I suspect that if they did, it would be under that subcommand and not under the auth subcommand. These commands are grouped as "Management commands". Based on this UX that we've evolved into, managing registry connections would have to be under: trivy registry subcommand (which is also under Management commands), i.e trivy registry login or trivy registry add).

The problem with this approach is that it might be confusing with registry scanning (which we don't support today).
Perhaps a better solution in hindsight would have been to move all those administrative commands under a subcommand trivy admin (not unlike the proposed trivy auth) including clean, module, plugin, vex, etc. that would remove any ambiguity and allow us to grow admin commands freely.

But coming back to reality, I guess trivy auth registry login is fine, and trivy registry login as well. I'd vote for the latter I think.

[itaysk]

I worte this before reading @simar7 's response :)

[knqyf263]

I don't mind trivy auth registry login or trivy registry login. I don't think it's a good idea to nest too many commands, so trivy registry login looks slightly better.

@DmitriyLewen @nikpivkin Any thoughts? If not, I'd go for trivy registry login.

[DmitriyLewen]

trivy registry login looks good to me.