In terms of infrastructure security, we would propose:
- Disable Demo site via FACEAPI_ENABLE_DEMO_WEB_APP="false" Environment Variable to avoid unnecessary worker utilization for serving site content and possible security issues raised by frontend vulnerabilities
- Do not expose service if possible. Access to the backend should be provided only via private tired networking.
- Use HTTPS connection where possible.
- Use firewall and limit incoming connections to apps by Firewalls/SecurtyGroups/Rules for only verified and authorized consumers (VMs/services).
- Use Load Balancer in front. In that case security configuration would be much smoother and more advanced. While it's still possible to terminate ssl connection and configure security specific headers in a faceapi container, let the service do the job it was created for-process request. The rest should be processed by the load balancer.
- Implement authorization, for example via Nginx and a plugin.
Below is an example configuration for docker deployment, but it can be easily adapted to all the provided platforms.
Option 1. Recommended. Nginx as a reverse-proxy
Run nginx as a frontend container for HTTPS processing and proxy service requests to the backend FACEAPI container. Here you can find the docker-compose.yml file and the Nginx default.conf file for a reference.
Option 2. FaceAPI via HTTPS
To run the FaceAPI service via HTTPS: - add 644 permissions to certificates so the server is able to read certificates - pass cert.crt & cert.key files to the container - pass FACEAPI_CERT_FILE, FACEAPI_KEY_FILE environment variables - forward container port to 8443 host port
chmod 644 ~/cert.crt ~/cert.key
docker run -it -p 8443:41101 -v ~/regula.license:/app/extBin/unix_x64/cpu/regula.license -v ~/cert.crt:/app/cert.crt -v ~/cert.key:/app/cert.key -e FACEAPI_CERT_FILE="/app/cert.crt" -e FACEAPI_KEY_FILE="/app/cert.key" regulaforensics/face-api