[P1BIGROCKS-2654](https://jira.il2.dso.mil/browse/P1BIGROCKS-2654) ## Problem: In a handful of Big Bang's images, plugins are added to the base image from Iron Bank and then resubmitted to Iron Bank under the big-bang repo. Compiled plugins are pulled as binaries from the upstream source. In some cases (e.g., Argo), the plugin dependencies and go version have not been updated in a long time. When they get to Ironbank, this results in numerous new findings as the old dependencies and go version ages. Because the plugins are sometimes from personal repos (@joshwolf :eyes:), it cannot be expected that they are kept up-to-date. Example: In Feb. 2022, ArgoCD was about 4 versions ahead of Big Bang. The plugins caused IB to stall on approval because of high and critical vulnerabilities found in GoLang 1.16.2 (among others). The plugins hadn't been recompiled in over a year. Building from source code was an option, but still delays the process. ## Goals 1. Break tight coupling between applications and plugins in Big Bang upgrades to allow applications and/or upgrades to be updated independently. Plugins will require identification of application compatibility. 2. Create pipeline for building and releasing in-house plugins 3. Identify information on each plugin to help with purpose, compatibility, maintenance, usage, etc. As part of this process, identify any plugins that Big Bang no longer needs to include. 4. Add flexibility to plugin consumption in Helm charts so deployments can add or remove plugins as needed ## Out of scope - BB does not have the resources to recompile and maintain every plugin from source code ## Proposed solution: - Perform reconnaissance on plugins to understand level of effort and decomposition of epic - For plugins identified as developed by P1 (or that P1 may need to fork due to inactivity), create a repo, pipeline, and code owners for maintaining. - Isolate each plugin into its own container with a copy utility. When run, the container would copy the plugin from one location to another. - Each plugin image would be submitted through the Iron Bank process - Helm charts would use a list of plugin images as values to create init containers. Each init container would have a shared volume mounted and used as the destination for the copy utility - The application using the plugins would mount the shared volume to its plugins directory - BONUS - Could also have the init container check for compatibility of the plugin by providing the app version as a ENV variable. The plugin image could already have an ENV that specifies the app versions it works for and produce a warning or error if its incompatible.