0.3.0-beta2: don't leak Authorization header from the registry to the redirected destination during @handle_redirects

README.md

@@ -43,7 +43,7 @@ docker run --rm --name docker_registry_proxy -it \
        -v $(pwd)/docker_mirror_certs:/ca \
        -e REGISTRIES="k8s.gcr.io gcr.io quay.io your.own.registry another.public.registry" \
        -e AUTH_REGISTRIES="auth.docker.io:dockerhub_username:dockerhub_password your.own.registry:username:password" \
-       rpardini/docker-registry-proxy:0.3.0-beta1
+       rpardini/docker-registry-proxy:0.3.0-beta2
 ```
 
 Example with GCR using credentials from a service account from a key file `servicekey.json`:
@@ -57,7 +57,7 @@ docker run --rm --name docker_registry_proxy -it \
        -e AUTH_REGISTRIES_DELIMITER=";;;" \
        -e AUTH_REGISTRY_DELIMITER=":::" \
        -e AUTH_REGISTRIES="gcr.io:::_json_key:::$(cat servicekey.json);;;auth.docker.io:::dockerhub_username:::dockerhub_password" \
-       rpardini/docker-registry-proxy:0.3.0-beta1
+       rpardini/docker-registry-proxy:0.3.0-beta2
 ```
 
 Let's say you did this on host `192.168.66.72`, you can then `curl http://192.168.66.72:3128/ca.crt` and get the proxy CA certificate.

nginx.conf

@@ -240,6 +240,12 @@ echo "Docker configured with HTTPS_PROXY=$scheme://$http_host/"
             set $original_uri $uri;
             set $orig_loc $upstream_http_location;
 
+            # during this process, nginx will preserve the headers intended for the original destination.
+            # in most cases thats okay, but for some (eg: google storage), passing an Authorization
+            # header can cause problems. Also, that would leak the credentials for the registry
+            # into the storage system (unrelated).
+            proxy_set_header      Authorization "";
+
             # nginx goes to fetch the value from the upstream Location header
             proxy_pass $orig_loc;
             proxy_cache cache;