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
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
The text was updated successfully, but these errors were encountered:
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)
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).
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.
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:
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
The text was updated successfully, but these errors were encountered: