Introducing Bridgr
In my professional career I have worked on a handful of projects, varying from large (100+ employee) programs to very small (5 employees). Most of those (because of the industry) necessitated the use of air-gapped systems for either development or deployment of software. In every case, I found that there wasn't a great process or tool to help facilitate getting a known set of artifacts from one side of that gap to the other.
So, I decided that I would do something about it. I started https://github.com/aztechian/bridgr so that there would be a common tool to help Bridge the air-gap (for artifacts). I have created a narrative story for Bridgr, in the spirit of Amazon's "6 pager". The problem statement, reasoning and detailed description of what Bridgr is (and is not) is discussed at length there. The narrative is a living document - PRs welcomed ;).
The takeaway is that Bridgr allows a new DevSecOps workflow to manage artifacts for air-gapped systems. A single configuration file in (human-readable!) YAML can precisely define artifacts for an entire (complex) system. That a concise "manifest" can be managed as code has significant ease-of-use and security implications
The Bridgr configuration file `bridge.yaml` should be kept in a Git repository, and can be separated or co-located with other code as appropriate. Changes to the configuration are now tracked by version control, and all of the benefits that provides: history, accountability, release management, and conflict resolution for artifacts. Security teams can now be involved in the process of dependency management, because Pull Requests for the configuration file can be reviewed by the security team prior to merging to mainline. It is even possible to make reviews by security mandatory before allowing merges. Furthering this DevSecOps interaction, the security team can actually code changes themselves: when a vulnerability is found, the security engineer can change the version of an artifact already in the configuration file and get concurrence from developers before merging into the baseline. The ease of YAML formatted files allows these interactions to be possible.
Integration with Jenkins or other CI engines is easy: define a tool installer, or just download the single executable. Then trigger a pipeline from the code repo with the configuration file, and run ./bridgr to get all your artifacts.
The output of Bridgr is complete, ready-to-use repositories for many different types of artifacts. As of Bridgr 1.0, File, YUM and Docker images are available but the plan is to support
- File
- YUM
- RubyGem
- PyPi (tgz and whl)
- Git
- Docker
- Jenkins Plugins
- NPM
- Maven
- Vagrant Box
The result is that you end up with pre-created metadata for all of the repository types, ready to host in a static web server on your air-gapped network (Nginx, Apache, S3, minio, etc).
Trust is an important topic with the systems where Bridgr would be used
Because Bridgr is to be a trusted tool in bringing data to potentially sensitive systems and networks, the trust and validity of Bridgr must be paramount. I decided to create Bridgr as an Open Source development project on GitHub so that transparency as to the quality and, ultimately trust of the community can be as high as possible – otherwise Bridgr is of no use. Potential community contribution was also a significant factor in going Open Source. A final factor was the availability of DevOps service integrations for Open Source projects on GitHub for no cost. These have deep integrations into GitHub services, and are the standard to which many open source developers now expect.
I believe the idea of Bridgr is a game changer for the people and processes involved with air-gapped systems, enabling a more DevOps and automated process for this subset of industries that otherwise get left out of the DevOps mainstream.