nginx:1.9 image not working with bcrypt encryption #860
Comments
|
This really ought to be reported over at
https://github.com/nginxinc/docker-nginx/issues, although I don't know of
any reason this shouldn't work if upstream nginx supports it, since the
image just installs the "nginx" package from upstream's APT repository.
|
|
Filed nginxinc/docker-nginx#29. |
|
Looks like nginxinc/docker-nginx#29 has been closed. Can anyone give this a try? |
|
It works fine with the current |
|
Thanks @fabfuel! 👍 |
|
"It still fails with the current nginx:stable or nginx:latest tags" and you conclude you can close the issue ? |
|
@TristanCP Try it with less snark. Remember that there is always a reason things are inconvenient. The reason this doesn't work with stable and latest is due to the exclusion of bcrypt from the base images. There is not much to be done without breaking people. @tianon Would it be possible to get bcrypt into the base image? Can we reach out to the nginx team to get this worked out? |
The nginx upstream issue is nginxinc/docker-nginx#29. My reading of that issue brings me to the conclusion that bcrypt is not in Debian's libc (or even upstream glibc; upstream bug to add bcrypt) so we can't really do anything about it, but the recommended workaround is to use the alpine based image since it does have bcrypt. |
|
@stevvooe Sorry I was just protesting against the closing process of some issues without giving any explanation. Please don't do this, it forces all people consulting these issues to do research to understand why it may be considered as "closed", instead of just reading the final comment of the closer. Many people won't even do the research part and just open an identical/similar issue when they don't understand the closing reason, so you just give yourself twice the work. Here I'd say : "bcrypt it not available in Debian image which is our base image for all official images. As a work around, if you need strong encryption on Debian, you can use "mkpasswd -m sha-512" to generate your passwords, or switch to our alpine base image". |
Apologies for the one-massive-commit. The main thing this does is adds an nginx authenticating proxy in front of prometheus, that puts basic auth in place. This is done by adding an nginx container into the task definition for prometheus, and using a `link` to allow nginx to access prometheus. Other things done in this commit: - we no longer specify `hostPort` values; we allow ECS to automatically assign host ports. The load balancer can still find our container, but we no longer have port conflicts when two concurrent versions of the service are deployed - reintroduce cpu quotas. because our instance has a total of 4096 cpu units available, and the default value is 1024, once we added nginx we had 3 containers and therefore couldn't run a new version of our service without killing the old version. Instead we set prometheus=1024, s3-config-grabber=256, nginx=256. - we use the nginx:alpine image rather than the plain `nginx` image. This is for two reasons: 1) it's smaller, and 2) the alpine image supports bcrypt: docker-library/official-images#860
Apologies for the one-massive-commit. The main thing this does is adds an nginx authenticating proxy in front of prometheus, that puts basic auth in place. This is done by adding an nginx container into the task definition for prometheus, and using a `link` to allow nginx to access prometheus. Other things done in this commit: - we no longer specify `hostPort` values; we allow ECS to automatically assign host ports. The load balancer can still find our container, but we no longer have port conflicts when two concurrent versions of the service are deployed - reintroduce cpu quotas. because our instance has a total of 4096 cpu units available, and the default value is 1024, once we added nginx we had 3 containers and therefore couldn't run a new version of our service without killing the old version. Instead we set prometheus=1024, s3-config-grabber=256, nginx=256. - we use the nginx:alpine image rather than the plain `nginx` image. This is for two reasons: 1) it's smaller, and 2) the alpine image supports bcrypt: docker-library/official-images#860
Apologies for the one-massive-commit. The main thing this does is adds an nginx authenticating proxy in front of prometheus, that puts basic auth in place. This is done by adding an nginx container into the task definition for prometheus, and using a `link` to allow nginx to access prometheus. Other things done in this commit: - we no longer specify `hostPort` values; we allow ECS to automatically assign host ports. The load balancer can still find our container, but we no longer have port conflicts when two concurrent versions of the service are deployed - reintroduce cpu quotas. because our instance has a total of 4096 cpu units available, and the default value is 1024, once we added nginx we had 3 containers and therefore couldn't run a new version of our service without killing the old version. Instead we set prometheus=1024, s3-config-grabber=256, nginx=256. - we use the nginx:alpine image rather than the plain `nginx` image. This is for two reasons: 1) it's smaller, and 2) the alpine image supports bcrypt: docker-library/official-images#860
The issue is discussed here: distribution/distribution#655
Generally, the issue is that nginx in provided image does not let to use bcrypt encrypted htpasswd created with -B key (
htpasswd -B ...). Most probably glibc package of image's OS (Debian Jessie) does not let to use bcrypt encryption.For example, the Basic Authentication manual leads to an auth error. Everything works good without using -B key when generating htpasswd but using standard apache md5 algorithm is insecure.
The text was updated successfully, but these errors were encountered: