Kaniko: Proxy question

[cref]

I'm trying to use the Kaniko executor behind a proxy. I'm using apk add in my Dockerfile. It works fine when I supply http_proxy as a --build-arg but I would expect that this shouldn't be necessary when there's already a proxy configured in ~/.docker/config.json. I know kaniko executor looks for credentials in this file so therefore is seems logical that this should also be supported.
Is this simply not supported or am I missing something?

Configure Docker to use a proxy server

[priyawadhwa]

Hey @cref, we don't currently support this -- right now we use a library which looks at the config.json and handles authentication and pulling/pushing images for us.

[bobcatfish]

@cref would you be able to provide the commands you are using to reproduce this? One issue could be that you need to mount the ~/.docker/config.json into the kaniko executor container in order for it to parse this (to /kaniko/.docker/config.json).

If that's not working for you then it could be a bug with go-containerregistry which we are using to parse the config.json 🤔

[Caligatio]

Just to add some more detail here:

Good News - It appears that go-containerregistry is respecting the proxy settings when pulling in base image(s)

Bad News - When the proxy is specified in the config.json, "normal" Docker essentially sets the HTTP_PROXY variable(s) temporarily within in the build container/context; kaniko does not. For instance if your Dockerfile has a RUN curl... command, that cURL will listen to the proxy settings specified in the host's config.json

This is a super helpful feature to have for those of us that are stuck with HTTP proxies as it allows the build to transparently handle needing a proxy without stamping any of that information into the end-product image.

[tequilarista]

triage - collapsing 'waiting for response' category into 'blocked'

[kfox1111]

We just hit this issue too

[giovanism]

My team hit this issue too. We would really like to see more discussion on this.

[leolb-aphp]

Also meeting that issue. Currently trying to figure out the best way to solve this as-is, will report back if I find a good workaround in the mean time to do it.

[ralph089]

We hit this issue too!

[pdefreitas]

For this one, it would be helpful if the executor had a flag to import all or specific environment variables (e.g. proxy settings) into the build-time variables. Setting up --build-arg with the necessary settings works as a workaround, kudos for the reporter for saving me some time.

[teedee22]

Here to second @pdefreitas suggestion!

[PMExtra]

Just to add some more detail here:

Good News - It appears that go-containerregistry is respecting the proxy settings when pulling in base image(s)

Bad News - When the proxy is specified in the config.json, "normal" Docker essentially sets the HTTP_PROXY variable(s) temporarily within in the build container/context; kaniko does not. For instance if your Dockerfile has a RUN curl... command, that cURL will listen to the proxy settings specified in the host's config.json

This is a super helpful feature to have for those of us that are stuck with HTTP proxies as it allows the build to transparently handle needing a proxy without stamping any of that information into the end-product image.

@donmccasland I think this is not area/registry, it's about build-time. Would you change the labels?

[PMExtra]

For now, I wrote the duplicate and cumbersome CI codes in every project:

    - /kaniko/executor
        $([ -n "${DOCKER_HUB_MIRROR}" ] && echo "--registry-mirror=${DOCKER_HUB_MIRROR}")
        --build-arg "ftp_proxy=${ftp_proxy}"
        --build-arg "FTP_PROXY=${ftp_proxy}"
        --build-arg "http_proxy=${http_proxy}"
        --build-arg "HTTP_PROXY=${http_proxy}"
        --build-arg "https_proxy=${https_proxy}"
        --build-arg "HTTPS_PROXY=${https_proxy}"
        --build-arg "no_proxy=${no_proxy}"
        --build-arg "NO_PROXY=${no_proxy}"

But in docker, I can do the same thing without any duplicate codes, I only need to change the config file once.
So I want someone to pay attention to this, it's a really useful and commonly feature.

Hint: there is no standard for these environments, most of applications work with the lower-case environments, but some others work with upper-case. So it's a more compatible solution to define both of them, just like the docker implementation.