Protecting Applications in Docker Containers
Sentinel LDK supports protected applications that execute in Docker containers, within the limitations described in this appendix.
The Product 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 appendix is applicable only for Docker containers under Linux unless except where stated otherwise.
>This appendix is applicable for applications that are protected and licensed using Sentinel LDK v.7.10 and later.
In this appendix:
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 - Outside of 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.
Using this option, a Linux container can be on either a Linux or Windows host.
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:
•One or more hosts in a local network (an SL key with concurrency)
•Single host in 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
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. However, you can only use this option with perpetual licenses that do not have a concurrency limit. Any other type of software licenses will be regarded as a clone the next time the container is restarted.
With this option, Thales recommends that you install the license at every container startup. This can be accomplished by simply placing the V2C file in the appropriate directory.
You should not save the container image after secure storage has been created. If the container image is saved, the secure storage would be regarded as "restored manually" at container startup and would be completely recreated automatically. This slows down the startup process.
>Option 3 - Mixed Solution
Type of Key | Location of Run-time Environment | Location of SL Key |
---|---|---|
SL AdminMode 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 OR on the host machine.
b. Use the License Manager in the RTE to install and activate the SL key on the host machine.
c.If you installed the RTE on the host machine:
i.Uninstall the RTE from the host machine.
ii.Install the RTE inside the Docker container.
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 - Outside of 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 network licenses 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 - Within Container
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
>Distribution of Docker images should be done before any license is installed. License activation should then be done after the user chooses the host they want to use. Distributing this container to other hosts will render this license unusable (regarded as cloned).
>An SL license of any type other than Perpetual that is installed in the container become a cloned license the next time the container restarts. To prevent this, do one of the following:
•Use one of the other installation options. The best option is to configure the secure storage on the host before installing the license.
•Request the user to provide a C2V from the host and install a license with concurrency of 1.
>When the License Manager operates in a Docker container: To configure the License Manager and establish communication between the License Manager and the protected application, you may need to configure the License Manager INI file. 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 appendix.
SL Key Options
Option 1: Outside of Container |
Option 2: Within Container | Option 3: Mixed Solution | |
---|---|---|---|
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 on the host and shared with 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 |
If the license is activated from a License Manager inside the Docker container, this option is identical to option 2. If the license is activated from a License Manager on the host, this option is identical to option 1. |
Expiration Date | Yes | No1 | |
Execution Count | Yes | No1 | |
|
Yes | No1 | |
Concurrency | Yes | No1 | |
Detach | Yes | Not applicable | |
Rehost | Yes (to another remote machine) | No | |
1This configuration will be blocked during license generation. Use option 1 with a single network seat or use option 3 with the license activated from the host. |
HL Key Options
Option 1: Outside of Container | Option 2: Within Container | |
---|---|---|
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 | Not applicable |
Rehost | Move the key | Move the key |