Protecting Applications in Docker Containers
Sentinel LDK licensing supports multiple deployment options for applications running in Docker environments. Depending on whether you use SL (software) keys or HL (hardware) keys, the Run-time Environment (RTE) and the license storage can reside on the host machine, in the container, or on both.
NOTE The RTE is only required to be installed for supporting license with concurrency or for legacy license key.
This flexibility allows you:
>Run protected applications inside containers.
>Choose where the License Manager and secure storage reside.
>Adapt to operational needs such as ephemeral containers, persistent volumes, or USB passthrough.
>Ensure compliance while maintaining performance and reliability across containerized deployments.
The license for a protected application that runs in a Docker container can be deployed using either HL keys or using SL keys, as described below.
NOTE
>This section is applicable for Docker containers under both Linux and Windows, except where stated otherwise.
>This section is applicable for applications that are protected and licensed using Sentinel LDK v.7.10 or later.
>Do not use the FQDN clone protection scheme in Docker containers if the License Manager runs inside a container without a fixed hostname. By default, Docker assigns random hostnames to containers, which can invalidate the fingerprint.
In this section:
Using SL Keys
Sentinel LDK supports the use of SL keys for protected applications that execute in a Docker container. The Run-time Environment can be installed on the host machine or within the Docker container.
The Run-time Environment and the SL key for a protected application that runs in a Docker container can be configured using one of the options described below.
>Option 1 - License with concurrency outside the container
| Type of Key | Location of Run-time Environment | Location of SL Key |
|---|---|---|
|
SL AdminMode key |
Host machine or remote machine | Host machine or remote machine |
The RTE and SL key are installed outside of the Docker container. This option does not have any limitations. The RTE works as usual. The protected application running in the Docker container accesses the license via network communication.
This option supports Linux containers on Linux or Windows hosts and Windows containers on Windows hosts.
This option relies on network connectivity, removing dependency on the host operating system. This option is different from local installation of an SL key, which requires Sentinel LDK to manage a local secure storage. As long as the application is running under an operating system that Sentinel LDK supports for consuming network licenses, the host environment (in the case of virtual machine or virtualized container) is of no importance.
If the host machine is a physical machine, you can prevent installation of SL AdminMode keys in the container by disabling support for virtual machines when you create the keys.
Thales recommends the use of Option 1 in the following scenarios:
•A server in a local network (an SL key with concurrency).
•A server in a the cloud (CL key) with the license configured with "Count Each Station" to define what is to be counted as a concurrent instance.
>Option 2 - Within Container (SL Keys Only)
| Type of Key | Location of Run-time Environment | Location of SL Key |
|---|---|---|
|
SL AdminMode key SL UserMode Key |
Within the container (RTE version must be 7.100 or later.) | Within the container |
You do not need to install anything on the host. This option is primarily for perpetual licenses. The license behavior depends on how you start the container:
•If you restart the container using docker restart, the secure storage is preserved and the license continues to work as expected.
•If you start the container using docker run (which creates a new container), a new secure storage is created. In this case:
–Previously installed Consumption-Based License fail to apply and return Error 78 (SECURE_STORAGE_ID_MISMATCH).
–Perpetual licenses (V2C) can be reapplied, but Feature ID 0 is disabled because of the storage ID mismatch. Do not use Feature ID 0 for applications protected with the API or the Envelope if you intend to run them in Docker containers using docker run.
With this option, Thales recommends that you install the license each time you create a container. This can be accomplished by simply placing the V2C file in the appropriate directory.
You should not save the Docker image after secure storage has been created. If the Docker image is saved, the secure storage would be regarded as "restored manually" at container startup and would be completely recreated automatically.
A feature is considered consumption-based if:
•It is a trial license, unless specifically configured to skip SSID checks.
•It is an execution counter license.
•It is an expiration or duration license on non-Android platforms.
•It is a detachable license.
•It is in a license key that is already consumption-based (rehost is enabled, or SSID checking is enforced for all).
•It has concurrency enabled to prevent abuse in Docker or Kubernetes environments with identical fingerprints.
>Option 3 - License storage outside the container
| Type of Key | Location of Run-time Environment | Location of SL Key |
|---|---|---|
|
SL AdminMode key SL UserMode Key |
Within the container (RTE version must be 7.100 or later.) | Host machine or remote machine |
To use the mixed solution, perform the procedures that follow.
Preparation:
a. Install the RTE inside the Docker container (applicable for SL AdminMode key).
NOTE If you installed the RTE on the host machine previously, uninstall the RTE from the host machine and install it inside the Docker container.
b. Use the License Manager in the RTE to install and activate the SL key.
Consuming licenses:
An application should consume a license from the SL key using the License Manager from the RTE installed inside the Docker container.
Additional considerations for the mixed solution:
You install the RTE inside the container, but configure Docker to keep the license storage directories on the host to be able to install any kind of license.
NOTE You cannot have a License Manager service running both inside the container and on the host. When using this option, ensure that the License Manager service executes only inside the container.
The host machine or remote machine (service) can supply a mounted persistence volume as SL storage. In a cloud environment, persistence volume is a resource that is backed by a persistent disk or volume service.
You can configure Docker to keep the license storage directories on the host using the Docker -v option. For example: The following command starts the "ubuntu" container, keeping the /var/hasplm and /etc/hasplm directories on the host.
$ sudo docker run -it -v /var/hasplm:/var/hasplm -v /etc/hasplm:/etc/hasplm -p 1947:1947 ubuntu
You can then install the RTE inside the container. (If the license storage directories already exist and contain licenses, you will be able to access these licenses from inside the container.)
Using HL Keys
Sentinel LDK supports the use of HL keys for protected applications that execute in a Docker container.
When installing Sentinel LDK Run-time Environment (RTE) for use with HL keys, the RTE can be installed either on the host machine or within the Docker container.
>Option 1 - License with concurrency outside the container
| Location of Run-time Environment | HL Key Access |
|---|---|
| Host machine | HL key accessed from the host machine |
The protected application running in the Docker container accesses the license on the HL key via network communication. Only licenses with concurrency are supported.
Thales recommends that you use this option if the license supports remote access. Access the HL key via the RTE and not directly from the Docker container.
>Option 2 - HL accessed via USB sharing
| Location of Run-time Environment | HL Key Access |
|---|---|
| Within the container (RTE version must be 7.100 or later.) | HL key accessed from inside the container |
This includes a scenario in which the Licensing API accesses the HL keys directly, without the need for the RTE.
When the RTE is installed within the Docker container, the host must be configured to share all USB devices with the container. You can accomplish this by issuing the following command on the host machine:
$ sudo docker run -it --device /dev/bus/usb:/dev/bus/usb ubuntu
It is also possible to share only the specific HL key by specifying the key's path, but you must implement some logic to identify this path. For example:
$ sudo docker run -it --device /dev/bus/usb/003/008:/dev/bus/usb/003/008 ubuntu
Additional Considerations
>Image Distribution & License Activation
Distribute Docker images before you install any license. Activate the license after the user selects the host to use. If you distribute the container to other hosts, the license becomes unusable and is considered as a clone.
>License Manager Configuration
When the License Manager runs inside a container, you need to configure the License Manager INI file to establish communication with the protected application and to reflect correct paths. For more information, see Working Directly With License Manager Configuration Files.
Side-By-Side Comparison
The tables that follow provides a side-by-side comparison of the different licensing options described in this section.
SL Key Options
|
Option 1: License with concurrency outside the container |
Option 2: Within Container (SL Keys Only) | Option 3: License storage outside the container | |
|---|---|---|---|
| Description |
CL key with concurrency on a remote machine or Docker host; supports cloud licensing if the host/container is in the cloud. SL keys (not cloud-enabled) are suitable if the host/container is in a local network. |
SL key and RTE inside the container. |
SL key (the license storage directories) on the host machine or remote machine and shared with the container. RTE inside the container. |
| Type of Key | SL AdminMode key |
SL AdminMode key SL UserMode key |
SL AdminMode key and SL UserMode key |
| Docker Host Requires Configuration? | No | No | Yes |
| Move the Container to Another Host Without Reactivation? | Yes | No | No |
| Supported License
|
|||
| Perpetual | Yes | Yes |
Yes |
| Expiration Date | Yes | Yes1 | Yes |
| Execution Count | Yes | Yes1 | Yes |
|
|
Yes | Yes1 | Yes |
| Concurrency | Yes | No2 | Yes |
| Detach | Yes | No2 | No |
| Rehost | Yes (to another remote machine) | No2 | Yes (to another remote machine) |
| 1On a container restart, licenses remain usable. On a new container, consumption-based licenses fail, while perpetual licenses apply but with Feature ID 0 disabled. 2Licenses with detach, rehost or concurrency are blocked during license generation. Use option 1 or 3 for licenses that include concurrency. |
|||
HL Key Options
| Option 1: License storage outside the container | Option 2: HL accessed via USB sharing | |
|---|---|---|
| Description | HL key with concurrency on a remote machine or Docker host | HL key (no concurrency) connected to the host and shared with the container |
| Type of Key | HL key | HL key |
| Anything Located Outside of the Container? | Yes (RTE on remote machine) | Only Physical key |
| Docker Host Requires Configuration? | No | Yes |
| Move the Container to Another Host Without Reactivation? | Yes | Yes |
| Supported License
|
||
| Perpetual | Yes | Yes |
| Expiration Date | Yes | Yes |
| ExecutionCount | Yes | Yes |
|
|
Yes | Yes |
| Time from License Generation | Yes | Yes |
| Concurrency | Yes | Yes |
| Detach | No | No |
| Rehost | Move the key | Move the key |