CodeMeter Support for Docker

CodeMeter Version 7.30 introduced a number of new features to improve the experience of working with protected applications in container systems like Docker. With the changes, CodeMeter now stays true to the basic principle of “one container, one application” and also includes a special form of binding for CmActLicenses in Docker containers.

On conventional operating systems, CodeMeter works according to a simple rule: the CodeMeter functions built into an application’s protection will find the necessary CodeMeter license server on the same system. But this straightforward setup is broken when working with Docker or similar container-based systems. An application running in one container could never find the CodeMeter license server in another container. The solution: Just create an additional network.

The CodeMeter network

The CodeMeter network needs to be connected with all containers involved, and all containers need to know the address of the container storing the CodeMeter license server. This is done by configuring the CODEMETER_HOST variable, which the CodeMeter libraries can read to make contact with the CodeMeter license server. The connection is treated by the license server as a local, not a network connection, which means that the license server can also use licenses that are made available by another host with CodeMeter as a network server.

How could this work in practice? Imagine an application that adds an effect to an image file. For every image that the user wants to process, a new container is set up with the protected image processing application as its entry point and with the image data and all relevant parameters as parameters. Each copy of the image processing application and each container is closed again once the job is done and the image altered. This means that if multiple images are processed at the same time, multiple containers will also exist in parallel. If the image processing app needs a CodeMeter license to run, it will contact the CodeMeter license server defined in its configuration and use up one license. When the application is closed, the license will be released again. In the normal run of things, there would be one container with the CodeMeter license server that all active copies of the image processing application would use.

A separate container is also used for all CodeMeter-specific interactions with the CodeMeter license server, like running a (single) CodeMeter WebAdmin or using the cmu command line tool to load licenses or list license information. The sample configuration provided by Wibu-Systems uses the same image as the container with CodeMeter license server does, but with other entry points.

Bound licenses

Another important innovation for Docker is the introduction of a new type of binding for CmActLicenses. The normal procedure for CmActLicenses is that they check certain hardware traits of the target system when they are created. These are then combined by the patented SmartBind process to form a clever fingerprint, so that the licenses would still work even if there are minor changes to the user’s system, but stop working if the system is altered substantially (or the user tries to run the license on a completely different system).

The challenge with Docker systems is that licenses should not be illicitly duplicated when a second copy of the CodeMeter license server’s container is created. The solution here lies in the use of a Named Volume. This Named Volume is placed in the container with the CodeMeter license server, and the CmActLicense then bound to that container and placed in the Named Volume. A special locking mechanism is added to stop the activated CmActLicense from being used multiple times, although it stays active when switching its container, e.g. when the container with the CodeMeter license server is switched to an image with a newer version of CodeMeter. Updating CodeMeter is made easy, as the user only needs to stop the old container and runone with the newer version. For the binding to work reliably and for CodeMeter to be able to check it, the container with the CodeMeter license server needs access to the Docker socket.

The malleability of a container environment means that CmActLicenses are not as easy to protect in a Docker container as they are on a physical system. This is why CmActLicenses still have to be activated explicitly for container environments (e.g. CmBoxPgm-Option -lopt:vm,container), and it makes sense to reconsider whether a license in a container is really needed.

Licenses in the cloud

Licenses in the cloud can be accessed without much difficulty from the (required local) container with CodeMeter license server. The licenses in a CmCloudContainer seem to exist directly in the Docker container, but they offer the best precautions against fraud and abuse. The number of active licenses seems to be tracked in the Docker container, but the CmCloud also counts and manages these licenses. It is impossible to use multiple copies of CmCloud licenses. If the Docker container has constant Internet access, putting licenses in a CmCloudContainer is a great choice.

Licenses in networks

The CodeMeter license server in a Docker container treats all license queries as if they were local. This means that licenses could also be used in a network as an alternative option to using CmActLicenses in separate Docker containers or CmCloudContainers. This approach only needs a computer that is permanently connected to the network and that has either one or more CmDongles connected or CmActLicenses activated. These licenses could then be used by the other devices in the network, including the Docker container with CodeMeter license server. That license server would be set as a client and told the name or address of the physical CodeMeter license server (taking over the master server role). Any license queries from applications are sent first to the CodeMeter license server in the Docker container and then forwarded to the network license server. Even if the applications are separated from their license server in this sense, they will still run as expected.

Other considerations

The Docker image containing the CodeMeter components needs to use a glibc-based Linux system. The examples use a lean image based on Debian. The next versions of CodeMeter will drop this requirement for containers with CodeMeter-protected applications. Wibu-Systems is currently working on the CodeMeter library and expansions to CodeMeter Protection Suite, so that protected applications can also run on Alpine, the Linux flavor popular for Docker environments.

 

KEYnote 42 – Edition Fall 2021