Docker deployment of NGINX for SSL termination with Keeper Connection Manager
Image: keeper/guacamole-ssl-nginx
keeper/guacamole-ssl-nginx is a Dockerized deployment of NGINX, built off Docker's official Nginx image which is pre-configured to provide SSL termination for Guacamole. It supports:
Usage of an existing certificate that you have already obtained from a certificate authority.
This image is produced as part of Keeper Connection Manager and made available under the same EULA. It is normally used to provide SSL termination for a container using the keeper/guacamole image.
The keeper/guacamole-ssl-nginx supports several mechanisms for generating, retrieving, or using existing SSL certificates. The mechanism used depends on which environment variables are specified when the Docker container is created.
In addition to these mechanism-specific environment variables, there is a set of environment variables that must always be specified:
ACCEPT_EULA - Whether you accept the Keeper Connection Manager EULA (acceptance of the EULA is required to use the image).
GUACAMOLE_HOSTNAME - The hostname/address of the Guacamole instance.
SSL_HOSTNAME - The public domain name that will be used to access Guacamole.
Let's Encrypt is used by default if no existing certificate is supplied and generation of a self-signed certificate is not requested. The keeper/guacamole-ssl-nginx image will reach out to the Let's Encrypt service using the "certbot" tool to retrieve an SSL certificate.
Only one environment variable specific to Let's Encrypt is strictly required if using Let's Encrypt certificates:
LETSENCRYPT_ACCEPT_TOS - Whether you accept the Let's Encrypt Terms of Service (acceptance of Let's Encrypt's Terms of Service is required to use that service).
In addition to accepting their Terms of Service, beware that Let's Encrypt strongly recommends providing an email address so that you can get important alerts regarding your certificate. You should additionally provide an email address unless you have a reason not to do so:
LETSENCRYPT_EMAIL - The email address to submit to Let's Encrypt when requesting the certificate.
If you are just testing usage of Let's Encrypt, you should use the Let's Encrypt staging/testing environment instead of the production environment:
LETSENCRYPT_STAGING - Set to "Y" to use Let's Encrypt's staging environment instead of production.
The retrieved certificate be automatically renewed by the image when necessary. If retrieval fails, the container will stop, details describing the failure will be logged, and the process will be retried the next time the container starts.
The keeper/guacamole-ssl-nginx image leverages Docker volumes to enable Let's Encrypt certificates and state to persist across container recreation.
For example, below will generate a Let's Encrypt certificate in your docker-compose.yml file:
If you already have a certificate that you obtained from a certificate authority, you can use that certificate by pointing to the relevant files with the CERTIFICATE_FILE and PRIVATE_KEY_FILE environment variables. The relevant files will need to be exposed to the image using Docker volume mounts.
CERTIFICATE_FILE - The full path to the certificate PEM file.
PRIVATE_KEY_FILE - The full path to the private key PEM file.
When your certificate comes up for renewal with your CA, you will need to replace the certificate and private key and reload NGINX. Stop and start the Docker Compose after the certificate has been updated.
For Docker Compose configuration, the example below will load a custom certificate from a shared volume that will hold the keys.
If deploying for testing, the image can automatically generate and maintain its own self-signed certificate:
SELF_SIGNED - Set to "Y" to automatically generate a self-signed certificate for testing.
The keeper/guacamole-ssl-nginx image will regenerate the self-signed certificate on startup. As the certificate expires 30 days after generation, the image will also automatically regenerate the certificate every 21 days to ensure it does not expire.
The certificate expiration date and fingerprints will be logged each time the certificate is regenerated, allowing rudimentary server identity verification.
In addition to the environment variables documented below, all environment variables supported by the official Docker Nginx image are accepted, as the official NGINX image forms the basis of this image.
ACCEPT_EULAThe ACCEPT_EULA environment variable must be set to "Y" to indicate your acceptance of the Keeper Connection Manager EULA. This Docker image may not be used except under the terms of the EULA.
SSL_HOSTNAMEThe public-facing hostname of the server hosting Docker. This environment variable is required and should be the full public domain name that will be used to access Guacamole over the internet, already associated with the IP address that reaches the server running Docker and this image.
GUACAMOLE_HOSTNAMEThe internal hostname or IP address of the Guacamole server. This environment variable is required, and should be the hostname/address that NGINX will connect to internally when servicing connections.
Note that the Guacamole service whose hostname/address is provided here should be reachable only on the internal network. Only the SSL terminating service (this image) should be public-facing.
GUACAMOLE_PORTThe TCP port number that the Guacamole server is listening on. This environment variable is optional. If omitted, the typical port 8080 will be used by default.
GUACAMOLE_CONTEXT_PATHThe path that Guacamole is being served beneath. This environment variable is optional. By default, this will be blank, representing that Guacamole is being served from the root path. As with the GUACAMOLE_CONTEXT_PATH environment variable of the keeper/guacamole image, this parameter may not contain slashes.
For example, if Guacamole is running internally at http://some-host/guacamole/, you would set GUACAMOLE_CONTEXT_PATH to guacamole.
SELF_SIGNEDIf set to "Y", requests that a self-signed certificate be automatically generated for SSL_HOSTNAME rather than using an existing certificate or retrieving a new certificate from Let's Encrypt.
Self-signed certificates are inherently insecure. This option should be used only for testing.
CERTIFICATE_FILE and PRIVATE_KEY_FILEThe paths of the PEM files for the SSL certificate and associated private key, respectively. These paths are relative to the filesystem of the Docker container. Externally-provided SSL certificate PEM files will need to be exposed within the container using Docker volume mounts.
These environment variables are only required if providing your own certificate. They will be ignored if using a self-signed certificate for testing with SELF_SIGNED.
LETSENCRYPT_ACCEPT_TOSIf intending to use Let's Encrypt, the LETSENCRYPT_ACCEPT_TOS environment variable must be set to "Y" to indicate your acceptance of the Let's Encrypt Terms of Service. Let's Encrypt cannot be used unless you agree to the relevant Terms of Service.
This environment variable is only required if using Let's Encrypt. It is ignored if providing your own certificate using CERTIFICATE_FILE and PRIVATE_KEY_FILE, or if using a self-signed certificate for testing with SELF_SIGNED.
LETSENCRYPT_EMAILThe email address that should be provided to Let's Encrypt when requesting a certificate. This environment variable is optional and is ignored if providing your own certificate using CERTIFICATE_FILE and PRIVATE_KEY_FILE, or if using a self-signed certificate for testing with SELF_SIGNED.
While this environment variable is optional, beware that Let's Encrypt strongly recommends providing an email address when obtaining a certificate using their service. From the help content for the certbot tool:
... This is strongly discouraged, because in the event of key loss or account compromise you will irrevocably lose access to your account. You will also be unable to receive notice about impending expiration or revocation of your certificates. Updates to the Subscriber Agreement will still affect you, and will be effective 14 days after posting an update to the web site.
LETSENCRYPT_STAGINGIf set to "Y", requests that the Let's Encrypt staging environment be used to retrieve an SSL certificate, rather than the production environment. This option should be used if you are just testing the Let's Encrypt functionality.
Content Security Policy (CSP) is a browser feature that allows web applications like KCM to declare to the browser what types of operations should be allowed in the context of that web application. In particular, CSP allows web applications to request that the browser block attempts to load resources or run scripts that the web application considers unsafe or unexpected. This is done by adding a Content-Security-Policy header to HTTP responses.
A default Content-Security-Policy header with known-good default value is set automatically by the keeper/guacamole-ssl-nginx image unless configured otherwise using the CONTENT_SECURITY_POLICY environment variable.
It is not typically necessary set this environment variable except in cases where custom KCM/Guacamole extensions require a more lenient policy.
Be careful if overriding the default policy is necessary. An overly-strict CSP can easily prevent KCM from performing core required tasks, such as decoding graphical data or making requests to its own REST API.
CONTENT_SECURITY_POLICYConfigures the value of the Content-Security-Policy header that will be sent in responses from Nginx.
If set to "Y", a reasonable default Content-Security-Policy value will be set that's known to work with most KCM installations: script-src 'self' 'unsafe-eval'; default-src 'self' data:; style-src 'self' 'unsafe-inline';. This configuration allows loading of assets from the same domain as KCM, along with allowing eval() for translations, and allowing JavaScript to dynamically load CSS.
If set to "N", the header will not be added to responses.
If this variable is set to any other value, the literal value of the variable will be sent with the response.
HTTP Strict Transport Security (HSTS) is a browser feature that allows the owners of a domain to advise browsers that connections should only use HTTPS, and that any HTTP connections should be upgraded to HTTPS before being sent.
As HSTS is not always appropriate for all deployments of KCM, particularly if KCM will share a domain with other web applications that do not all support HTTPS, installations of KCM do not enable HSTS by default.
The STRICT_TRANSPORT_SECURITY environment variable must be set to a value to enable HSTS. A recommended default is available for convenience.
STRICT_TRANSPORT_SECURITYConfigures the value of the Strict-Transport-Security header that will be sent in responses from Nginx.
If set to "Y", a reasonable default Strict-Transport-Security value will be set: 'max-age=31536000; includeSubDomains; preload;' always, as recommended by https://https.cio.gov/hsts/.
If set to "N", the header will not be added to responses.
If this variable is set to any other value, the literal value of the variable will be sent with the response.
Rather than pass data directly in environment variables, a _FILE suffix may be added to any environment variable supported by this image to force that variable to be read from the named file within the container. As Docker secrets store sensitive data within files beneath /run/secrets/ within the container, this can be used to load sensitive data from Docker secrets.
For example, to load the Let's Encrypt account email from Docker secrets:
The environment variables in this section are only needed in unusual cases, such as when serving KCM from a non-standard port or when older ciphers or versions of SSL must be enabled. Do not set these variables unless you are certain that doing so is necessary.
SSL_CIPHERSConfigures the allowable SSL ciphers for the Nginx instance. For information on the allowable values for this parameter, see the Nginx documentation. If not otherwise specified, the value will default to "HIGH:!aNULL:!MD5".
SSL_PROTOCOLSConfigures the allowable SSL protocols for the Nginx instance. For information on the allowable values for this parameter, see the Nginx documentation. If not otherwise specified, TLS 1.2 and 1.3 will be enabled.
SSL_EXTERNAL_PORTConfigures value of the X-Forwarded-Port header that will be sent to the KCM web application in requests from Nginx. This header advises the KCM server know that SSL requests are being received at a non-standard port.
If a non-standard port is used for SSL, this port must additionally be mapped to the standard port, e.g. -p 8443:443. Setting this variable has no impact on the ports used by Nginx internally within the image.
If not specified, KCM will expect that inbound requests are coming from the standard HTTPS port (443).
ADDITIONAL_CONFIGArbitrary configuration for the server block that points at the KCM web application in the Nginx configuration files generated by this image.
This variable functions as a catch-all for applying Nginx configuration options that do not have corresponding environment variables in the keeper/guacamole-ssl-nginx image.
Any value provided via the ADDITIONAL_CONFIG environment variable will be included in the main server block pointing at the KCM web application. Only configuration options that Nginx will accept within a server block may be included here.