feat: plugin Index

[knqyf263]

Motivation

Trivy recently added support for output plugins (#4863). To further promote plugin adoption, I propose creating a plugin index.

Plugin Index

Inspired by Krew, the proposed plugin index follows a similar concept. We will create a trivy-plugin-index repository to manage the list of plugins, similar to krew-index. An HTML page will be generated to display the plugin list and hosted on GitHub Pages, just like Krew's plugin list.

Additionally, an index file in YAML format will be created and hosted on GitHub Pages. Trivy will download and use this index file locally.

Usage

The usage will be as follows:

# First, refresh your local copy of the plugin index:
$ trivy plugin update

# To list all plugins available, run:
$ trivy plugin search

# You can specify search keywords as arguments:
$ trivy plugin search aqua

# To get more information on a plugin:
$ trivy plugin info aqua

Currently, trivy plugin update is used to update existing plugins. We will change this behavior to use it to download the index. An announcement will be made regarding this breaking change.

A new command trivy plugin upgrade will be introduced for updating plugins.

Plugins listed in the index can be installed without specifying the URL. Trivy will transparently retrieve the repository URL from the index and perform the installation.

$ trivy plugin install kubectl

Installing custom plugins not registered in the index will still be possible using the following command:

$ trivy plugin install github.com/aquasecurity/trivy-plugin-kubectl 

Developer Guide

We will also create a Developer Guide that documents not only how to develop plugins but also how to register them in the index.

[DmitriyLewen]

Sounds really cool!

Plugins listed in the index can be installed without specifying the URL. Trivy will transparently retrieve the repository URL from the index and perform the installation.
$ trivy plugin install kubectl

Perhaps we want to add namespace for plugins (e.g. aqua/kubectl).
My thoughts on this matter:
We need to choose who will support new plugins.

• If Trivy team (or another team) will support all plugins - I think there is no point in creating namespace. If plugin author wants - we can add field with info about authors.
• But if plugin authors do this (I mean logic, as is case with community tools such as https://aquasecurity.github.io/trivy/v0.51/ecosystem/ide/#trivy-pre-commit-community . mxab itself supports pre-commit) - it makes sense to add username as a namespace. For example, other users can write to him that his plugin needs updating or discuss new functionality with him. I mean that it will be easier for other users to find and contact the author of the plugin.

[knqyf263]

Since everybody, including Aqua, can create a plugin, I also lean toward namespaces. It is also easier to distinguish which plugins are managed by Aqua. However, Krew doesn't have them. It's simpler if we don't have to add it. Also if we add namespaces, it can be a bit confusing because the name when you install (e.g. aqua/kubectl) and the name when you run the plugin (e.g. trivy kubectl) are different.

[nikpivkin]

Will the user have the option to install a specific version of the plugin? For example, in krew-index only the latest version of the plugin is specified.

[DmitriyLewen]

I'm worried that if number of plugins is large, it will be good if there is some kind of structure for plugins (they will be sorted somehow) so that it is convenient to find them.
But I do not instruct on this.

it can be a bit confusing because the name when you install (e.g. aqua/kubectl) and the name when you run the plugin (e.g. trivy kubectl) are different.

If we do add namespaces, I think we should use full name (namespace + name) of plugin to run it.

[knqyf263]

Will the user have the option to install a specific version of the plugin? For example, in krew-index only the latest version of the plugin is specified.

Yes, trivy plugin install aqua/[email protected] should be available.

[knqyf263]

If we do add namespaces, I think we should use full name (namespace + name) of plugin to run it.

brew install aquasecurity/trivy or go install github.com/kubernetes/kubectl will enable commands like trivy and kubectl. I think it's common to use an unscoped name after installation. The point is an installed plugin behaves like a subcommand, such as trivy kubectl. trivy aqua/kubectl doesn't look like a subcommand.

[DmitriyLewen]

hm... I think you convinced me.
The namespace will be inconvenient in our use case.

[knqyf263]

Personally, I would like to add namespace, but I am concerned that I am introducing unnecessary complexity.

Of course, if there are more than 1,000 plugins, namespace is absolutely necessary, but even Krew has only 245 plugins, so it is expected that Trivy will have even fewer than that. In that case, we need to consider whether the convenience of the namespace or the complexity it brings is greater.

I'm torn between both methods, as they are both good and bad.

[knqyf263]

Also if we add namespaces, it can be a bit confusing because the name when you install (e.g. aqua/kubectl) and the name when you run the plugin (e.g. trivy kubectl) are different.

I feel like it's common.

$ brew install kubernetes-cli
==> Downloading https://formulae.brew.sh/api/formula.jws.json
############################################################################################################################################################# 100.0%
==> Downloading https://formulae.brew.sh/api/cask.jws.json
############################################################################################################################################################# 100.0%
kubernetes-cli 1.29.3 is already installed but outdated (so it will be upgraded).
==> Downloading https://ghcr.io/v2/homebrew/core/kubernetes-cli/manifests/1.30.0
############################################################################################################################################################# 100.0%
==> Fetching kubernetes-cli
==> Downloading https://ghcr.io/v2/homebrew/core/kubernetes-cli/blobs/sha256:814cc8afddfeecf6711bab4909effceae88ad789e35685e5432cd3b9ba06b079
############################################################################################################################################################# 100.0%
==> Upgrading kubernetes-cli
  1.29.3 -> 1.30.0
==> Pouring kubernetes-cli--1.30.0.arm64_sonoma.bottle.tar.gz
==> Caveats
zsh completions have been installed to:
  /opt/homebrew/share/zsh/site-functions
==> Summary
🍺  /opt/homebrew/Cellar/kubernetes-cli/1.30.0: 235 files, 54.3MB
==> Running `brew cleanup kubernetes-cli`...
Disable this behaviour by setting HOMEBREW_NO_INSTALL_CLEANUP.
Hide these hints with HOMEBREW_NO_ENV_HINTS (see `man brew`).
Removing: /opt/homebrew/Cellar/kubernetes-cli/1.29.3... (234 files, 59.4MB)
Removing: /Users/teppei/Library/Caches/Homebrew/kubernetes-cli_bottle_manifest--1.29.1... (7.3KB)
Removing: /Users/teppei/Library/Caches/Homebrew/kubernetes-cli_bottle_manifest--1.29.3... (7.3KB)

$ kubernetes-cli
zsh: command not found: kubernetes-cli

/ # pip install awscli
Collecting awscli
  Using cached awscli-1.32.99-py3-none-any.whl (4.5 MB)
...
Installing collected packages: urllib3, six, PyYAML, pyasn1, jmespath, docutils, colorama, rsa, python-dateutil, botocore, s3transfer, awscli
  Attempting uninstall: urllib3
    Found existing installation: urllib3 2.2.1
    Uninstalling urllib3-2.2.1:
      Successfully uninstalled urllib3-2.2.1
Successfully installed PyYAML-6.0.1 awscli-1.32.99 botocore-1.34.99 colorama-0.4.6 docutils-0.16 jmespath-1.0.1 pyasn1-0.6.0 python-dateutil-2.9.0.post0 rsa-4.7.2 s3transfer-0.10.1 six-1.16.0 urllib3-1.26.18

/ # awscli
sh: awscli: not found

How do people know the binary name...?

[knqyf263]

Another example

/ # npm install -g @angular/cli

added 236 packages in 39s

44 packages are looking for funding
  run `npm fund` for details
/ # @angular/cli
sh: @angular/cli: not found

The installed binary name is ng.

/ # ng version

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/


Angular CLI: 17.3.6
Node: 22.1.0 (Unsupported)
Package Manager: npm 10.7.0
OS: linux arm64

[DmitriyLewen]

I think they install applications using instructions (e.g. https://pypi.org/project/awscli/).
Then all plugins should have clear instructions and we should check this when adding a new plugin.

[simar7]

Personally, I would like to add namespace, but I am concerned that I am introducing unnecessary complexity.

Of course, if there are more than 1,000 plugins, namespace is absolutely necessary, but even Krew has only 245 plugins, so it is expected that Trivy will have even fewer than that. In that case, we need to consider whether the convenience of the namespace or the complexity it brings is greater.

I'm torn between both methods, as they are both good and bad.

I would vote for no namespaces, simply to reduce complexity.

Later on, if we ever decide to introduce namespaces, it won't be particularly hard as most likely we will begin by creating an "aqua" namespace (and updating all our plugins, which is in our control). While the rest of the plugins can be in the "community" namespace, unless the creators of those plugins decide to implement their own namespaces.

[knqyf263]

After discussion, we seem to have agreed on no namespace. However, I'll add a maintainer field in the plugin definition file so that the namespace can be added in the future. Thanks for the feedback!