Skip to content

Is there interest in some form of MITM for build? #3959

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

Open
apostasie opened this issue Mar 2, 2025 · 2 comments
Open

Is there interest in some form of MITM for build? #3959

apostasie opened this issue Mar 2, 2025 · 2 comments

Comments

@apostasie
Copy link
Contributor

apostasie commented Mar 2, 2025

What is the problem you're trying to solve

I have been messing around with build lately to get the nerdctl Dockerfile under control and speed-up and make more reliable the test-integration targets (will come soon in a different PR).

As part of that, I started MITM-ing network traffic from the build - initially using third party tools - but now I have a (very nasty) patch that does nerdctl build --mitm ... which captures traffic on its own, spitting out information about TLS or plain traffic information at the end of the build (domains, number of requests, size, time, errors, etc).

Question is: are we interested in incorporating such a thing in nerdctl main?

I can see a couple of reasons to do that:

  • do what I do - aka, audit the network traffic going on from building a specific Dockerfile (performance, security, reverse-engineering, whatever)
  • have some form of network error resiliency for build, by possibly retrying failing requests
  • have the ability to rewrite requests on the fly? (reverse-engineering again?)

The patch is currently awful but serves my purpose.

Turning it into something ready for mass-consumption is likely a lot of work, and I would rather check first if there is any interest in mainlining this.

Vote with your thumbs 👍🏽 👎🏽 :-)

Describe the solution you'd like

na

Additional context

No response

@AkihiroSuda
Copy link
Member

SGTM, how is this implementable?
Would it be possible to merge the implementation in https://github.com/moby/buildkit ?

Relevant:

@apostasie
Copy link
Contributor Author

SGTM, how is this implementable?

a. on nerdctl build, start the proxy part in the background (somewhat straight-forward but a good chunk of work - would go for a transparent proxy)
b. route traffic from the container - either pass along _PROXY environment variables or go the transparent route redirecting traffic with iptables
c. make sure the container trusts the proxy CA (we touched on that discussion the other day) - I think this is the touchy bit - right now I am rewriting the Dockerfile on the fly to inject a secret on all RUN --mount=type=secret,uid=100,id=CA, and the right args under any FROM ARG SSL_CERT_FILE=/run/secrets/CA, ARG GIT_SSL_CAINFO=/run/secrets/CA to bypass the CA store.

Point c is the tricky one of course.

I think short term / the least intrusive way would be to come up with a custom frontend and tell people to use # syntax=containerd/nerdy-frontend at the top of their files if they want the feature.
(I need to refresh on this as I haven't done that in a while)

Would it be possible to merge the implementation in https://github.com/moby/buildkit ?

For a deeper integration into buildkit that would benefit all frontends, really the only thing needed would be the ability to automatically add a certain mount so that we get the CA in there (would have to look into the details as well).

Relevant:

Thanks ^.

Ideally, we would not have to run anything in the containerd - just a combination of the right environment variables and getting the CA in there one way or the other.

Anyhow, I'll keep playing with this and come back here when I have a firmer design.

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

No branches or pull requests

2 participants