Security is everyone’s job. With NGINX Unit, security is at the forefront of the server’s design. Unit naturally separates applications by spawning separate processes for each one, enabling isolation at the process and memory layer. Each application process can be owned by separate users, enabling security at the file permission layer as well. Finally, NGINX Unit has full SSL/TLS support, which enables Unit to serve applications through encrypted HTTPS communication. All of these security attributes are demonstrated in this chapter.
You need to serve multiple applications and would like them to be fully isolated.
Configure the applications separately in NGINX Unit. Unit creates separate processes for each application, enabling isolation.
{
"applications"
:
{
"auth-service"
:
{
"type"
:
"php"
,
"processes"
:
10
,
"root"
:
"/var/www/auth/"
,
"index"
:
"index.php"
},
"key-service"
:
{
"type"
:
"external"
,
"processes"
:
2
,
"executable"
:
"/var/key-service"
}
}
}
NGINX Unit comprises two main processes and the application processes. The controller process serves the API interface used to configure Unit. The router process handles incoming requests and queues them for the application defined by the listener configuration. Each application is run as a separate process or group of processes.
You need to further isolate your applications by using user permissions.
Use a different system user for each application so that Unit spawns the processes as separate users with their own permissions.
{
"applications"
:
{
"auth-service"
:
{
"type"
:
"php"
,
...
"user"
:
"auth-app"
},
"key-service"
:
{
"type"
:
"external"
,
...
"user"
:
"key-app"
}
}
}
Unit runs each application as a separate process or group of processes, enabling it to run these processes as separate system users. When configuring an application in Unit, there is an attribute for user and group. Using separate system users for each application will provide your applications with further isolation.
You need to secure your application’s communication with SSL/TLS certificates.
Create a .pem
file that includes your certificate chain and private key:
cat cert.pem ca.pem key.pem |
sudo tee bundle.pem > /dev/null
Upload the bundle.pem file created in the last step to Unit’s certificate storage under a suitable name:
sudo curl -X PUT --data-binary @bundle.pem--unix-socket /var/run/control.unit.socket
http://localhost/certificates/certificate-name
Configure a listener object to use the certificate. In this example, a file with the object will be written to a file named tls-listener.json for clarity:
{
"*:8443"
:
{
"pass"
:
"applications/app-name"
,
"tls"
:
{
"certificate"
:
"certificate-name"
}
}
}
Submit the tls-listener.json configuration to the Unit API:
This command removes all other listeners that might have been defined prior.
sudo curl -X PUT -d @tls-listener.json--unix-socket /var/run/control.unit.socket
http://localhost/config/listeners
Validate that your application is communicating over TLS:
curl -v https://localhost:8443
This recipe concatenates the certificate, certificate authority chain, and key into a bundle that can be used by NGINX Unit. After the certificate is uploaded to Unit’s certificate store, it can be referenced by listeners. A listener object is constructed that references the IP and port on which to accept requests and that references the application via the pass
attribute, as well as the certificate bundle object. The listener object is then submitted to the Unit control interface.
Validating that the TLS certificate is configured properly can be done by making a request to the listener. Using the verbose flag, -v
, when issuing the curl
command will print the TLS handshake operations if the certificate is configured properly.
3.129.67.26