Enhance the Trivy plugin index

[knqyf263]

Overview

The current schema for the trivy-plugin-index is very simple:

name: count
repository: github.com/aquasecurity/trivy-plugin-count

This simplicity is due to the presence of plugin.yaml in the plugin repositories, which is automatically crawled by CI to extract necessary information and deploy it using GitHub Pages: index.yaml.

Considerations

Versioning

The YAML itself does not include versioning; instead, the HTTP path has a v1 prefix (https://aquasecurity.github.io/trivy-plugin-index/v1/index.yaml) to prevent Trivy from breaking due to destructive changes in the index schema. Revising the index.yaml schema might be beneficial, considering the potential inclusion of metadata in the future.

Automatic Crawling

The advantage of automatic crawling is the elimination of duplicate definitions. However, there is a risk of breakage if incorrect changes are made to plugin.yaml in the plugin repository. On the other hand, if plugin.yaml breaks, it would also prevent installation via Trivy, so excluding it from the index might be beneficial.

Tracking index.yaml

Currently, index.yaml is automatically generated on CI and deployed to GitHub Pages. There should be a discussion on whether this file should be managed with Git.

Security

Security is a crucial consideration. The plugin repository may change, posing risks. However, this risk is inherent to the plugins themselves, as stated in the documentation, and not due to the automatic crawling of the index.

[knqyf263]

@DmitriyLewen What do you think?

[DmitriyLewen]

We will need to merg 2 PRs - add plugin to plugins directory + update index.json.
Do you have reason why you don't want to just push commit with updated index.json after merging PR with new/removed/updated plugin?

[knqyf263]

I thought we wanted to review the generated index manually. Do you want to automate it?

[DmitriyLewen]

Do you want to automate it?

We will need to check new/updated/removed plugin (2 lines (name + repository)). So I think, yes, we can automate this.

[knqyf263]

How about this workflow?
cf3c352

[DmitriyLewen]

looks good 👍

[knqyf263]

I learned from that mistake and decided to add metadata this time, as Trivy initially had a schema that could not have metadata, which required destructive changes to the schema later on.
7f5002a

[DmitriyLewen]

Agree with your idea.

https://aquasecurity.github.io/trivy-plugin-index/v1/index.yaml

Perhaps we can rename v1 to index (as example) to avoid confusion if we will use version 2 but store file in v1 directory.

[knqyf263]

Regardless of the file schema, we should have a prefix in the endpoint. Otherwise, an older Trivy will be broken with v2.

[knqyf263]

With version prefix:

• New Trivy with v2 support: Access https://aquasecurity.github.io/trivy-plugin-index/v2/index.yaml
• Old Trivy with only v1 support: Access https://aquasecurity.github.io/trivy-plugin-index/v1/index.yaml.

Without version prefix:

• New Trivy with v2 support: Access https://aquasecurity.github.io/trivy-plugin-index/index/index.yaml successfully
• Old Trivy with only v1 support: Access https://aquasecurity.github.io/trivy-plugin-index/index/index.yaml and fail

Another benefit of having a version in the index YAML is that people can probably use any HTTP path when they use custom indexes (Trivy doesn't yet support it, though).

[DmitriyLewen]

Got it. You are right - we need to use version prefix 👍