| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | sbassett | T289290 Design and Build Application Security Pipeline Components for Gitlab | |||
| Resolved | brennen | T289292 Create Security Team group within gitlab.wikimedia.org | |||
| Resolved | sbassett | T289293 Create initial proof of concept application security pipeline repository | |||
| Resolved | mmartorana | T301831 Create nancy ci yaml template |
Event Timeline
Hey Release-Engineering-Team - so we hit a snag here trying to use the available golang images under docker-registry.w.o. All of them switch to the user nobody after setup (good!) but unfortunately that inhibits us from doing things like apt-update and apt install to get us a few more tools we need to install and verify the nancy binary, or build it from source. Our current thoughts are:
- Use one of the official golang/debian images from docker hub (e.g. golang:1.17-bullseye)
- Use sonatype's official nancy image
- Build a new golang-devel image under docker-registry.w.o that functions a bit more like the other (node, python) devel images we've been successfully using for various gitlab ci templates
The first two options obviously break with our plan to use more trusted and stable images under docker-registry.w.o and I'm not completely certain if external images will be allowed in this particular gitlab ci context (T291978)? The third option would require a bit more work and assistance from your team.
Hey @sbassett we don't have a lot of precedent for the first two options here, although this may be something to consider in future. I could image a simple version of option 3 that publishes a releng/golang image that uses our golang image and changes the user (living somewhere in integration/config.
It looks like you're trying to use this on GitLab is that correct? If that's the case maybe we can add this image to our "trusted images" as discussed on T291978: Limit GitLab shared runners to images from Wikimedia Docker registry -- @brennen do you have thoughts on that?
Hey @thcipriani - so we did find a bit of a workaround for our current golang-nancy ci template. We're just using the base docker-registry.wikimedia.org/bullseye image and installing the linux-amd64 nancy binary release from sonatype's github releases page (and validating checksums) This seems to work fine with Gopkg.lock files though we'll need to install debian's golang-go package to help us process go.mod files. I think using more basic debian images and/or -devel images should get us to where we need to be, since many of the security tools we're implementing aren't as version-dependent or task-specific as other images under docker-registry.wikimedia.org. Anyhow, let me know if this sounds acceptable - I feel like it should be a decent compromise that lets us do what we want to do while avoiding the use of third-party images or rolling our own specific, low-use images.
This is done for now. It's still in a test branch for now, and so will need to be merged to main and production at some point (I plan to create a task for that within this hierarchy).