forked from TrueCloudLab/distribution
Merge pull request #981 from LouisKottmann/master
Add exemple proxy mistake whith nginx sitting behind an ELB
This commit is contained in:
commit
f651c5d68e
1 changed files with 22 additions and 4 deletions
|
@ -17,7 +17,7 @@ Usually, that includes enterprise setups using LDAP/AD on the backend and a SSO
|
|||
|
||||
### Alternatives
|
||||
|
||||
If you just want authentication for your registry, and are happy maintaining users access separately, you should really consider sticking with the native [basic auth registry feature](deploying.md#native-basic-auth).
|
||||
If you just want authentication for your registry, and are happy maintaining users access separately, you should really consider sticking with the native [basic auth registry feature](deploying.md#native-basic-auth).
|
||||
|
||||
### Solution
|
||||
|
||||
|
@ -25,13 +25,31 @@ With the method presented here, you implement basic authentication for docker en
|
|||
|
||||
While we use a simple htpasswd file as an example, any other nginx authentication backend should be fairly easy to implement once you are done with the exemple.
|
||||
|
||||
We also implement push restriction (to a limited user group) for the sake of the exemple. Again, you should modify this to fit your mileage.
|
||||
We also implement push restriction (to a limited user group) for the sake of the exemple. Again, you should modify this to fit your mileage.
|
||||
|
||||
### Gotchas
|
||||
|
||||
While this model gives you the ability to use whatever authentication backend you want through the secondary authentication mechanism implemented inside your proxy, it also requires that you move TLS termination from the Registry to the proxy itself.
|
||||
|
||||
Furthermore, introducing an extra http layer in your communication pipeline will make it more complex to deploy, maintain, and debug, and will possibly create issues.
|
||||
Furthermore, introducing an extra http layer in your communication pipeline will make it more complex to deploy, maintain, and debug, and will possibly create issues. Make sure the extra complexity is required.
|
||||
|
||||
For instance, Amazon's Elastic Load Balancer (ELB) in HTTPS mode already sets the following client header:
|
||||
|
||||
```
|
||||
X-Real-IP
|
||||
X-Forwarded-For
|
||||
X-Forwarded-Proto
|
||||
```
|
||||
|
||||
So if you have an nginx sitting behind it, should remove these lines from the example config below:
|
||||
|
||||
```
|
||||
X-Real-IP $remote_addr; # pass on real client's IP
|
||||
X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
X-Forwarded-Proto $scheme;
|
||||
```
|
||||
|
||||
Otherwise nginx will reset the ELB's values, and the requests will not be routed properly. For more informations, see [#970](https://github.com/docker/distribution/issues/970).
|
||||
|
||||
## Setting things up
|
||||
|
||||
|
@ -127,7 +145,7 @@ Now, start your stack:
|
|||
|
||||
docker-compose up -d
|
||||
|
||||
Login with a "push" authorized user (using `testuserpush` and `testpasswordpush`), then tag and push your first image:
|
||||
Login with a "push" authorized user (using `testuserpush` and `testpasswordpush`), then tag and push your first image:
|
||||
|
||||
docker login myregistrydomain.com:5043
|
||||
docker tag ubuntu myregistrydomain.com:5043/test
|
||||
|
|
Loading…
Reference in a new issue