Transport Layer Security

The container admin can manage transport layer security using environment variables and a keystore file, along with a password file to access the keystore.

By default, the container provides access using the HTTPS protocol while HTTP is disabled. When the container admin starts a container, the following environment variables must be set:

Variable Name Default Value Description
PRIVATE_AI_HTTPS_ENABLED

True

When set to true, HTTPS will be the only supported protocol. If set to false, HTTP will be enabled and the other SSL environments will be ignored.

If omitted, the default value of true is used.

PRIVATE_AI_SSL_CERT_TYPE

"PKCS12"

The certificate format for the SSL key store.

Valid values are "PKCS12" and "JKS".

The container uses TLS 1.3; other TLS versions are not accepted. The container only uses the following ciphers:

  • TLS_AES_128_GCM_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256

Clients that attempt to connect with ciphers that are not included in the list will be rejected with an SSL error.

In addition to setting the environment variables, the container admin must also create a keystore file. The keystore must be named "keystore" and contain the private key and any certificates required to be presented to clients. The format of this file should be consistent with the format specified in the PRIVATE_AI_SSL_CERT_TYPE variable. An extension to the file is not required but if one exists, It must be .pk12 or .pfx for the PKCS12 format or .jks for the JKS format.

Because these files exist on the host system, they must be mounted onto the container file system. The container will only look for these files under /privateai/ssl in the container file system, therefore, the host directory containing the keystore should be mounted by the container admin at that location.

For example, if the keystore is stored at /opt/security/keystore.pk12, the container admin could use the following commands to start the container with SSL support (this example assumes Podman is the container engine):

podman run -e PRIVATE_AI_CONFIG_FILE=/privateai/config/config.json
  -e PRIVATE_AI_ENABLE_SSL=true
  --secret keystore --secret key_pwd
  -v /opt/security:/privateai/ssl -v /opt/models:/privateai/models
  -p 9090:8443 <container_name>

The container admin also must generate a password file so that the container can access the keystore. For example:

cd /opt/.secrets
openssl genrsa -out key.pem
openssl rsa -in key.pem -out key.pub -pubout
openssl pkeyutl -in pwdfile.txt -out pwdfile.enc -pubin -inkey key.pub -encrypt
rm -rf /opt/.secrets/pwdfile.txt

The container admin can then create secrets in the container. The following example uses Podman but similar commands are available for Docker:

podman secret create keystore /path/to/ssl/myKeystore.p12
podman secret create key_pwd -

The secretsSetup.sh script helps in the creation of secrets. For more information about the script and where to download the file, see Configure the Private AI Services Container.