diff --git a/proposals/2023/03-16_scheduled-builds.md b/proposals/2023/03-16_scheduled-builds.md index 7b35e615..d2f32a3d 100644 --- a/proposals/2023/03-16_scheduled-builds.md +++ b/proposals/2023/03-16_scheduled-builds.md @@ -1,4 +1,4 @@ -# Build Tokens +# Scheduled Builds + +| Key | Value | +| :-----------: | :----------------: | +| **Author(s)** | Jordan Brockopp | +| **Reviewers** | TBD | +| **Date** | January 20th, 2026 | +| **Status** | Reviewed | + + + +## Background + + + +**Please provide a summary of the new feature, redesign or refactor:** + + + +The idea is one unique feature that would cover two distinct use-cases: + +1. As an administrator (platform admin) of a Vela instance, I want to restrict (block) certain container images from being used in a pipeline that we know are not valid. As an example, imagine one (or more) images that were designed for a specific use-case (i.e. service) that no longer exists (i.e. decommissioned). Another example would be images that were managed by a team that no longer exists (i.e. disbanded). In either scenario, the images are likely old and out-of-date (potentially years) so they're riddled with vulnerabilities and should be considered a security risk to the company. I fully acknowledge that this could be jarring to end-users which is where the second use-case comes into play. +2. As an administrator of a Vela instance, I want to promote awareness for certain container images being used in a pipeline that we know are subject to cause issues in the future. Per the examples from the first use-case, if I know a service is being decommissioned sometime in the future, I'd like to highlight that to end-users leveraging specific images (i.e. plugins) designed to interact with that service. Another example would be highlighting that a specific image or version of an image is deprecated (i.e. bug, vulnerability etc.) so I should upgrade to the latest version. + +> NOTE: This is considered one feature because it supports configuration at different levels (i.e. block vs warn). + +**Please briefly answer the following questions:** + +1. Why is this required? + + + +* Please see the description and background for the use-cases. + +2. If this is a redesign or refactor, what issues exist in the current implementation? + + + +* N/A + +3. Are there any other workarounds, and if so, what are the drawbacks? + + + +* Not directly through Vela + +4. Are there any related issues? Please provide them below if any exist. + + + +* https://github.com/go-vela/community/issues/1066 + +## Design + + + +**Please describe your solution to the proposal. This includes, but is not limited to:** + +* new/updated endpoints or url paths +* new/updated configuration variables (environment, flags, files, etc.) +* performance and user experience tradeoffs +* security concerns or assumptions +* examples or (pseudo) code snippets + + + +The idea is have one or more images configured on the "warn" list for a period of time. Any images used in a pipeline from this list would surface a "warning" on the `Pipeline` tab for a build similar to the behavior added for the YAML migration: + +https://github.com/go-vela/community/blob/main/proposals/2024/12-04_yaml-migration.md + +Ideally, we'd also highlight this on the `Builds` page to indicate that a respective build in the list had warnings. Depending on the interest, we could also try to surface these warnings on the `Audit` tab for a respective build. + +Then, when the Vela administrators feel sufficient time has been given, they could "promote" the container image from the "warn" list to the "block" list. The significance of this change would be that the compiler for Vela would reject (throw an error) if an image on the "block" list was used thus preventing a build from even being created. This would use the same `error` field in the `hooks` table that we use for other compilation failures: + +https://go-vela.github.io/docs/usage/troubleshooting#why-is-my-build-not-displaying + +### Option 1 + +This option involves updating the [go-vela/server](https://github.com/go-vela/server) codebase to support ingesting an optional YAML file at startup. If the YAML file is valid, and matches the expected syntax from Vela, the server ingests it and then uses it to make determinations based off the images used in the pipeline depending on the configured "block" and/or "warn" lists. + +Here's a simple, rough draft to demonstrate a potential example of the syntax for the YAML file: + +```yaml +--- +block: + - image: docker.example.com/disbanded-team/* + reason: This image has been blocked by Vela administrators as the team that owns it has been disbanded:\n + - image: docker.example.com/deprecated-image:* + reason: This image has been blocked by Vela administrators as the image is no longer supported:\n + - image: docker.example.com/valid-team/deprecated-version: + reason: The version of this image has been blocked by Vela administrators as it is no longer supported:\n + - image: docker.example.com/valid-team/vulnerable-image:* + reason: This image has been blocked by Vela administrators due to the vulnerabilities associated with it:\n + +warn: + - image: docker.example.com/disbanded-team/* + reason: The team that owns these images has been disbanded so support for these will be blocked in the future:\n + - image: docker.example.com/deprecated-image:* + reason: This image has been deprecated so support for these will be blocked in the future:\n + - image: docker.example.com/valid-team/deprecated-version: + reason: The version of this image has been deprecated so support for this will be blocked in the future:\n + - image: docker.example.com/valid-team/vulnerable-image:* + reason: This image has vulnerabilities that put the company at risk so support for this will be blocked in the future:\n +``` + +### Option 2 + +This option involves updating both the [go-vela/server](https://github.com/go-vela/server) and [go-vela/ui](https://github.com/go-vela/ui) codebases to support creating, updating and deleting individual values from the registry via the "site admin" page: + +https://vela.example.com/admin/settings + +The idea would be to have the server store configuration for both the "block" and "warn" lists directly in the database. This means the API (server) would have to offer new API endpoints to support CRUD operations for these lists. Also, the UI would have to be updated to support interacting with these new API endpoints. There is the potential for the UI page to support configuring these lists as a YAML file for configuration but it wouldn't be a requirement as we could adopt a similar approach to secrets where users can restrict the usage of secrets to specific container images. + +## Implementation + + + +**Please briefly answer the following questions:** + +1. Is this something you plan to implement yourself? + + + +* TBD based off the option we choose but yes, for at least the backend (API) portion + +2. What's the estimated time to completion? + + + +* TBD based off the option we choose + +**Please provide all tasks (gists, issues, pull requests, etc.) completed to implement the design:** + + + +* N/A + +## Questions + +**Please list any questions you may have:** + + + +* N/A diff --git a/proposals/2026/README.md b/proposals/2026/README.md new file mode 100644 index 00000000..f88890fd --- /dev/null +++ b/proposals/2026/README.md @@ -0,0 +1,7 @@ +# Proposals + +This directory is meant to house a historical record of all potential features and modifications to be made to Vela in 2026. + +## Index + +- [01/20 Image Registry](01-20_image-registry.md): contains proposal information for warning about or blocking images in pipelines. diff --git a/proposals/README.md b/proposals/README.md index 1c4812ae..a9ca09b5 100644 --- a/proposals/README.md +++ b/proposals/README.md @@ -5,11 +5,15 @@ To create a new proposal, make a PR into master using the [template](https://git ## Index +### 2026 + +- [01/20 Image Registry](2026/01-20_image-registry.md): contains proposal information for warning about or blocking images in pipelines. + ### 2024 -- [12/27 Dynamic ruleset](2024/12-27_dynamic-ruleset.md): contains proposal information for enhancing `ruleset` to be more dynamic. - [03/07 Platform Settings](2024/03-07_platform-settings.md): contains proposal information for `platform settings` and dynamic configurations. - [12/04 YAML Migration](2024/12-04_yaml-migration.md): contains proposal information for `yaml migraton` to go-yaml v3. +- [12/27 Dynamic ruleset](2024/12-27_dynamic-ruleset.md): contains proposal information for enhancing `ruleset` to be more dynamic. ### 2023