This repository has been archived. There will likely be no further development on the project and security vulnerabilities may be unaddressed.
This repository contains a simple Python application which is used to provide authentication and authorization for the NGINX Ingenious application. The Ingenious application has been developed by the NGINX Professional Services team to provide a reference architecture for building your own microservices based application using NGINX as the service mesh for the services.
The Auth Proxy Service is configured to validate authentication tokens and route requests to other components in the NGINX Microservice Reference Architecure:
- Album Manager Service
- Content Service
- Pages
- Photo Resizer Service
- Photo Uploader Service
- User Manager Service
In addition, the Auth Proxy Service is configured to use an external service named fake-s3. In a production environment, the application would use a real Amazon S3 implementation. For the purposes of a sample or reference application, we use an image provided by lphoward.
The default configuration for all the components of the MRA, including the Auth Proxy service, is to use the Fabric Model Architecture. Instructions for using the Router Mesh or Proxy Model architectures will be made available in the future.
As a single service in the set of services which comprise the NGINX Microservices Reference Architecture application, Ingenious, the Auth Proxy service is not meant to function as a standalone service. Once you have built the image, it can be deployed to a container engine along with the other components of the Ingenious application, and then the application will be accessible via your browser.
There are detailed instructions for building the service below, and in order to get started quickly, you can follow these simple instructions to quickly build the image.
- (Optional) If you don't already have an NGINX Plus license, you can request a temporary developer license here. If you do have a license, then skip to the next step.
- Copy your licenses to the /mra-auth-proxy/nginx/ssl directory
- Run the command
docker build . -t <your-image-repo-name>/auth-proxy:quickstart
where is the username for where you store your Docker images - Once the image has been built, push it to your image repository with the command
docker push -t <your-image-repo-name>/auth-proxy:quickstart
At this point, you will have an image that is suitable for deployment on to a Kubernetes installation, and you can deploy the image by creating YAML files and uploading them to your Kubernetes installation.
To build a customized image for different container engines or to set other options, please follow the directions below.
The Dockerfile for the Auth Proxy service is based on the python:3.5 image, and installs NGINX open source or NGINX Plus. Note that NGINX Plus includes features which make discovery of other services possible, include additional load balancing algorithms, create persistent SSL/TLS connections, and provide advanced health check functionality.
Please refer to the comments in the Dockerfile for details about each command which is used to build the image.
The command, or entrypoint, for the Dockerfile is the oauth-start.sh script. This script sets some local variables, then starts oauth_daemon.py and NGINX in order to handle page requests.
The Dockerfile sets some ENV arguments which are used when the image is built:
-
USE_NGINX_PLUS
The default value is true. When this value is set to false, NGINX open source will be built in to the image and several features, including service discovery and advanced load balancing will be disabled. See installing nginx plus -
USE_VAULT
The default value is false. Setting this value to true will cause install-nginx.sh to look for a file named vault_env.sh which contains the VAULT_ADDR and VAULT_TOKEN environment variables to retrieve NGINX Plus keys from a vault server.#!/bin/bash export VAULT_ADDR=<your-vault-address> export VAULT_TOKEN=<your-vault-token>
You must be certain to include the vault_env.sh file when USE_VAULT is true. There is an entry in the .gitignore file for vault_env.sh
In the future, we will release an article on our blog describing how to use vault with NGINX.
-
CONTAINER_ENGINE
The container engine used to run the images in a container. CONTAINER_ENGINE can be one of the following values- kubernetes (default): to run on Kubernetes When the nginx.conf file is built, the fabric_config_k8s.yaml will be used to populate the open source version of the nginx.conf template
- mesos: to run on DC/OS When the nginx.conf file is built, the fabric_config.yaml will be used to populate the open source version of the nginx.conf template
- local: to run in containers on the machine where the repository has been cloned When the nginx.conf file is built, the fabric_config_local.yaml will be used to populate the open source version of the nginx.conf template
Set the USE_NGINX_PLUS property to false in the Dockerfile
Before installing NGINX Plus, you'll need to obtain your license keys. If you do not already have a valid NGINX Plus subscription, you can request developer licenses here
Set the USE_NGINX_PLUS property to true in the Dockerfile
By default USE_VAULT is set to false, and you must manually copy your nginx-repo.crt and nginx-repo.key files to the /mra-auth-proxy/nginx/ssl/ directory.
Download the nginx-repo.crt and nginx-repo.key files for your NGINX Plus Developer License or subscription, and move them to the root directory of this project. You can then copy both of these files to the /nginx/ssl directory of each microservice using the command below:
cp nginx-repo.crt nginx-repo.key <repository>/nginx/ssl/
If USE_VAULT is set to true, you must have installed a vault server and written the contents of the nginx-repo.crt and nginx-repo.key file to vault server. Refer to the vault documentation for instructions configuring a vault server and adding values to it.
As described above, the CONTAINER_ENGINE environment variable must be set to one of the following three options. The install-nginx.sh file uses this value to determine which template file to use when populating the nginx.conf file.
- kubernetes
- mesos
- local
Replace <your-image-repo-name> with the username for where you store your Docker images, and execute the command below to build the image. The <tag> argument is optional and defaults to latest
docker build . -t <your-image-repo-name>/auth-proxy:<tag>
In order to run the image, some environment variables must be set so that they are available during runtime.
Variable Name | Description | Example Value |
---|---|---|
REDIS_HOST | The host name of the redis database | redis.localhost |
REDIS_ENABLED | Specifies whether the redis database is enabled, valid values are 0 or 1 | 1 |
REDIS_PORT | The port on which redis listens | 6359 |
REDIS_TTL | The redis timeout in seconds | 300 |
AWS_ACCESS_KEY_ID | The AWS access key ID for the associated S3 account | Refer to your AWS account |
AWS_SECRET_ACCESS_KEY | The AWS secret access key for the associated S3 account | Refer to your AWS account |
PAGES_URL | The host name of the pages application | pages.localhost |
AWS_REGION | The region of the AWS application | us-west-1 |
FLASK_DEBUG | (Optional) The server will reload itself on code changes. It will also provide a debugger | True |
GOOGLE_CLIENT_ID | The Google client ID for the associated account | Refer to your Google Account |
GOOGLE_CLIENT_SECRET | The Google client secret for the associated account | Refer to your Google Account |
FACEBOOK_APP_ID | The Facebook app ID for the associated account | Refer to your Facebook Account |
FACEBOOK_APP_SECRET | The Facebook app secret for the associated account | Refer to your Facebook Account |
Method | Endpoint | Description | Parameters |
---|---|---|---|
GET | / | Authenticates the user based on request headers and cookies. Performs auth_request directive | |
GET | /status.html | Shows the NGINX Plus status page | |
GET | /status | Displays the NGINX Plus status JSON |
In this service, the nginx/ssl/dhparam.pem file is provided for ease of setup. In production environments, it is highly recommended for secure key-exchange to replace this file with your own generated DH parameter.
You can generate your own dhparam.pem file using the command below:
openssl dhparam -out nginx/ssl/dhparam.pem 2048