search

ArmyCyberInstitute / cmgr

CTF Challenge Manager
Apache License 2.0
18 stars 9 forks source link

Add "freeze" to the API and commands #26

Closed jrolli closed 3 years ago

jrolli commented 3 years ago

As part of the discussion about making it easier to drop in the Dockerfile for a challenge to support debugging (#24), @dmartin suggested adding support to lock in the versions and dependencies at a known-good state to prevent library changes from breaking the challenge in the future. The proposed change is to add support for private repositories and change the image build process to as follows:

  1. Check the repo for a frozen build ({{repo_url}}/{{challenge_slug}}:{{version_hash}}), and pull if it exists.
  2. Build the challenge, using the frozen build as the build cache if it exists.

The freeze process would be:

  1. Look for a build stage labeled base (returning an error if it does not exist).
  2. Build base locally.
  3. Push base to the private repo tagging it with the version hash.

At this time, there is no plan to directly support for "unfreezing" a challenge (but the freeze command would be capable of pushing an updated base image). This mostly stems from the Docker API not exposing a method for deleting images from a registry through the Docker daemon. While it is possible to hit the registry's API directly, we are currently relying on the daemon's credential cache for authentication so adding the functionality would require asking for and handling the authentication tokens.

jrolli commented 3 years ago

@dmartin, I pushed an update that implements this functionality (v0.10.0) but wanted to get your input before marking this as closed. Do you have any thoughts on whether this is sufficient to meet your use-case? Happy to discuss out-of-band (email or video call) as well if that is easier.

dmartin commented 3 years ago

This should be very helpful, thanks for working on this feature! Sorry for the late response, but I will test this out within the next couple of days and let you know if we run into any issues.

dmartin commented 3 years ago

@jrolli, I tried this out with a few challenges and I think this will work well for us. It's a pretty simple/elegant way of addressing the reproducibility issue when moving between Docker daemons. Thanks again!