Block plugins with a reason and an optional remedy

[colindean]

Description

Vela could have a configuration file that could enable blocking images/plugins.

A use case is to block old plugin versions. A conversation with a user highlighted that some folks are using ancient versions of Vela plugins. We want to think that folks have a dependency updater such as Renovate configured to get updates, but they might not.

I think Vela could have a denylist of images. That list could include a reason for each (e.g. “outdated and may not work”) and a remedy (e.g. “upgrade to a more recent version”).

Value

• Enhance security by allowing or denying images
• Provide a clear reason for the denial
• Provide clear instructions for remedying a denial, such as alternative images to use or simply a nudge to use a newer version

Definition of Done

• A configuration file populates a list of images that should be blocked along with metadata about the blockage
• A configuration file populates a list of allowed images
• After hydrating a pipeline configuration, the images to be retrieved are checked against these lists¹.
• If all images are allowed, proceed.
• If any image is denied, halt the build job with an error and show the triplet (image url, reason, remedy).
• Highlight the image URL in the pipeline config, if possible.

Effort (Optional)

Lots, potentially.

Impacted Personas (Optional)

Vela administrators would bear the brunt of the new powers, but some UX is needed for Vela users to get the information in the most actionable way.

Footnotes

1. If allowlist is configured, if the image isn't in the list, deny it with a reason code along the lines of "not in the allowlist" and remedy of "use something else. If the denylist is configured, look up and get the reason/remedy. ↩

[colindean]

This configuration file is best suited to be a Starlark file. Why? There's a lot to be programmed here, and YAML or JSON would lead to too much copying and pasting.

pythons_eol = [ "3." + n for n in range(0, 9) ]

def main(ctx):
  return {
    "allowlist": None, # [] would block everything
    "denylist" : build_denylist(ctx),
  }

def eol():
  return "Image is end-of-life."
def newer():
  return "Use a newer version. Consider trying the latest release."

def python_eol(version):
  key = "python:" + version
  reason = "Python " + version + " is EOL." # IIRC Starlark doesn't have f-strings
  remedy = "Use a newer Python version"
  return {key: (reason, remedy)}

def build_denylist(ctx):
  return {
    "python:latest": ("Latest is unsafe.", "Use a specific version"),
    "python:2.7": ("Python 2.7 is ancient and EOL.", "Upgrade to Python 3.x"),
    "target/vela-artifactory:v0.0.1": (eol(), newer())
  } | { python_eol(version) for version in pythons_eol }

[jbrockopp]

Funny, I came here to write up a similar ticket because we (Cargill) have this need ourselves.

However, our use-case is slightly different because we're looking to restrict specific versions of Docker images but also specific paths to Docker images. Additionally, we're hoping to hook into the existing pipeline warnings functionality which was originally added for the Vela compiler changes introduced a couple releases ago:

https://github.com/go-vela/community/blob/main/proposals/2024/12-04_yaml-migration.md

The idea would be to able to configure a "registry"? (list of Docker images) that when referenced in the pipeline they'd show up in the Pipelines tab as a warning. Ideally, we'd also be able to highlight on the Builds page that there were warnings associated with the pipeline for that respective build.

Additionally, we'd like to configure another "registry" but this would be a list that's exclusively blocked. So if Vela processes a pipeline with an image from that registry then the build would immediately fail. Perhaps we even take this a step further and have the failure higher in the stack... so not even create a build for the repo but rather a compilation failure.

To explain some scenarios for our use-cases:

• One or more plugins which were originally designed for a tool that has now been deprecated and is scheduled for decommission in the future. The idea would be to configure the Docker image(s) for the tool on the warning list for an extended period of time (i.e. months). Then, when all parties are aligned, we'd move the image(s) from the "warning registry" to the "denied? (blocked? etc.) registry" so they no longer can be used entirely.
• One or more plugins which were originally associated with a team that no longer exists. In this scenario, the Docker images being referenced may be extremely old and out-of-date (i.e. years) so they're riddled with vulnerabilities and should be considered a security risk to the company. Again in this scenario, we'd like to put these on a "warning registry" for an extended period of time to promote awareness until a point we deem it viable to promote them to the "blocked registry".

[jbrockopp]

After some further discussions with Sussman, an alternative (another option?) may be something such as:

https://github.blog/news-insights/product-news/supercharging-github-actions-with-job-summaries/

The idea being the deprecated plugins send a specifically crafted log message that appears at the top of the build page.

[wass3rw3rk]

After some further discussions with Sussman, an alternative (another option?) may be something such as:

https://github.blog/news-insights/product-news/supercharging-github-actions-with-job-summaries/

The idea being the deprecated plugins send a specifically crafted log message that appears at the top of the build page.

wouldn't that necessitate a semantic version bump on those plugins. otherwise that would only be effective if we re-released to the same version (which we don't do).

Perhaps we even take this a step further and have the failure higher in the stack... so not even create a build for the repo but rather a compilation failure.

yes, that would be ideal, i think.

This configuration file is best suited to be a Starlark file.

i think this would likely be stored in the database and managed via API/UI by admins? or are you suggesting that the enpoint takes a starlark file as input?

[wass3rw3rk]

As a follow-up, we chatted about this in our Committer's Sync and @jbrockopp @JordanSussman volunteered to open a proposal for this as a next step. 🙏🏼

[jbrockopp]

@wass3rw3rk I've written up an initial proposal and have provided it to some folks internally for review.

Once our side (Cargill) has aligned on the proposal, we'll look to open up a PR following the official process.

We hope to submit that PR sometime next week so we'll keep you posted if anything changes.