Authentication

Without proper authentication, our server is wide open to anyone accessing it so we add a username/password combo to act as a gatekeeper to our service:

ARG PASSWORD=test
...
RUN printf "user:$(openssl passwd -1 $PASSWORD)
" >> $SRV_PATH/.htpasswd

ARG acts as a build-time substitute for an ENV directive and allows the password to be passed in as a build argument with --build-arg <arg>. If the build is not provided with one, it should default to the argument after the equals sign, which is a very insecure test in this case. We will use this variable a bit lower in the Dockerfile to create the .htpasswd file with a specific password for our user.

The second line uses openssl, which we installed earlier, to take this build arg and create the .htpasswd file with encrypted credentials in a format that NGINX and most other web servers can understand (<username>:<hashed_password>).

Warning! Keep in mind that the -1 algorithm is less secure than the Salted SHA (SSHA) method of creating .htpasswd passwords, but to create them in this way would have involved more complicated commands that would have distracted from our main purpose here, but you can visit https://nginx.org/en/docs/http/ngx_http_auth_basic_module.html#auth_basic_user_file for more details. Also be aware that you should never use online password generators as they can (and often do) steal your entered information.

If you haven't worked with Bash sub-shells before, $(openssl ...) is run in a separate shell and the output is substituted as a string variable before the rest is evaluated so the >> append operation will only see the encrypted password after username: and nothing related to openssl. As it should be somewhat apparent from these things, if we don't provide any build arguments, the container will have a single username user with a password set to test.

Warning! This type of credential passing to the image is used here as an example and is very nonsecure since anyone can run docker history and see what this variable was set to or start the image and echo the PASSWORD variable. In general, preferred ways of passing this type of sensitive data are through environment variables when you launch the container, mounting the credentials file as a volume onto the container, using docker secret, or an external credentials sharing service. We may cover some of these in later chapters, but for now, you should just keep in mind not to use this particular way of passing credentials in production due to security concerns.

With the web_server piece finished up, we can move to the next piece: the database.

Table of Contents for Authentication

Create new playlist

Sign In

Sign Up

Table of Contents for
Authentication