# Using containers behind an authenticating web proxy

Authenticating web proxies are an inconvenient fact of life, in that some applications simply will not run correctly behind one. However, many can be made to work simply by setting the http_proxy and possibly also the https_proxy environment variables. The rest of this post assumes the user is in fact behind such a proxy, and for the sake of simplicity, discusses only http_proxy. Such statements should be taken to also refer to https_proxy in environments where that is in fact required. Recall the syntax using http_proxy with an authenticating web proxy is as follows:

http_proxy="http://<user>:<password>@<proxyhost>:<proxyport>"


Obviously, to fetch rkt images, it is necessary to have http_proxy defined in the user’s environment on the host.

To run a web-aware containerized application in a rkt pod, it is necessary to also have http_proxy defined inside the pod. A simple way to do this is to pass in this environment variable. When using rkt as root, this may be achieved in various ways, as described in the rkt documentation.

When using rktrunner, this may be achieved by the following configuration file snippet.

[environment]
http_proxy = "{{.http_proxy}}"


Note how the environment variable is referenced using Go template syntax, as described in the rktrunner documentation.

If http_proxy is defined in the user’s environment, rktrunner will be pass it into the pod, using rkt --set-env-file, using a file with carefully controlled permissions. The point is, http_proxy probably contains the user’s password, and should not be passed on the command line, as that would make the password visible to ps and the like.

Configuring the pod networking and DNS may also be necessary, in particular if the web proxy hostname is defined only in a private DNS server, e.g.

[options.common]
run = [
"--net=host",