You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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 todocker-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 bydocker-build-push
with the required secrets. So it might be necessary for the base image to be bootstrapped (built and pushed locally once).The text was updated successfully, but these errors were encountered: