Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it problematic that docker-build-push docker cache is shared between projects? #44

Open
ScottG489 opened this issue Apr 5, 2022 · 0 comments

Comments

@ScottG489
Copy link
Owner

Are there any security implications? The docker-build-push image is building separate projects, but they're all sharing the same cache. I think this should be OK as long as there isn't a way for someone to abuse the inputs to docker-build-push to run malicious code. I haven't actually audited it, so right now this could be a problem. However, I think this is really a problem for any image that's run on conjob.

For instance, a job has run and caches a build which may have secrets on it. Then a malicious user runs the job again with inputs that run some malicious code. (Thinking about this, isn't this a problem with GitHub Actions even? For instance PR's causing builds to run automatically, but those PRs could edit the workflow file or something else in the build to expose secrets?).

It also means that only one of the jobs can be running at a single time since you can't have more than one instance of a job that's accessing the docker cache shared between them. Not even pertaining to the docker cache, this is a bit of an annoying limitation.

I'd have to think this through more thoroughly, but it got me wondering if we even need docker-build-push.

Could you somehow have an image that built itself? It would probably have to be bootstrapped, but then perhaps it would just need to be parameterized to either build and push or run the actual project build.

Perhaps there should be something like a base image per project on which everything runs on top of? This way they are entirely "namespaced" separately from other builds. The base image would just need dockerd installed and running and then it could build the CI build image (maybe wouldn't even need to push it?) and then run that image to do the actual CI build. The base image could be built by conjob too, but I think this might just get us back to the security and partially the single instance problem (though maybe less so since it should never change and would build from cache every time?) because the base image would still need to be built by docker-build-push with the required secrets. So it might be necessary for the base image to be bootstrapped (built and pushed locally once).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant