Container systems like Docker are becoming an increasingly popular choice for running applications in isolation. Containers are simple to use and easy to duplicate. Software developers have a legitimate interest in protecting and securely licensing their applications even in such container environments. This article reveals how the ability to use, copy, and multiply containers can be reconciled with the wish to license software correctly, and how Docker can cooperate with CodeMeter.
The idea of operating software in containers is not new. The basic functionality has long been part of the Linux operating system, and the Docker project has put a user-friendly container solution into the hands of the masses. Docker has reached critical mass and established itself as the leading provider of container technology. Since Microsoft decided to integrate Docker’s containers into Windows Server 2016 and Windows 10, the world has come to recognize Docker as the de-facto standard in its field.
There are many benefits to running applications in a container. In essence, containers are small virtual machines (VMs) without their own operating system. They share the host system’s OS kernel and important system files, making them much leaner than full-blown VMs providing the same services. This makes them cheaper to run, as the setup uses fewer resources and fewer systems need to be maintained (with updates, security patches, etc.).
Containers do not have to load the operating system, resources, or libraries on startup. Instead they can directly access the components and data of the operating environment. With no operating systems having to be installed, additional containers can also be added much faster. When the process is automated, the setup scales perfectly – one reason why containers are becoming more and more popular.
Despite all of this good news, one must not ignore the drawbacks. Compared to traditional virtualization technologies, the individual containers are not as well-isolated from each other or their host. The processes running in the containers also share the same system libraries and the same kernel, which can cause compatibility issues. Vulnerabilities or software bugs can pose real problems when using containers and might affect the system in its entirety.
How does CodeMeter behave in this environment, and what do software developers and license vendors have to remember? How can you use containers, but keep in control of your licenses? From the brief overview above, one can see how easy it would be to copy a license created and bind it to a container. One installation of a CodeMeter license server in one container would essentially not differ at all from another one in another container. The binding properties would be identical. In order to run multiple installations of the CodeMeter license server in separate containers on a single host, several specific changes were needed: In CodeMeter 6.90, two areas needed to be changed that influence operations in a container.
The first concerns the types of CmActLicenses that are allowed to operate in a Docker container. CodeMeter Version 6.90 generally prohibits their activation and use – with two specific exceptions. The first are licenses without a concrete binding to the system hardware (NoneBind) that allow multiple imports (Reimport). These licenses serve only as a means for decrypting applications, but without any license restrictions at all, in essence forming a “Protection Only” use case. In the future, this use case would be replaced by the new IP Protection mode in CodeMeter Protection Suite (see this issue of KEYnote for more details). Since this type of CmActLicense has no license restrictions, there is no risk of fraud when the same license is used in multiple containers. The second exception are CmActLicenses specifically approved for this use. Software developers can set a new option for CmActLicenses that allows them to be activated in a container. The command line option in CmBoxPgm is „-lopt:container“, usable only for Universal Firm Codes.
The second area concerns a change in how binding works with network interfaces. In order to reduce the possible exposure to possible attacks – not just for containers, but for all licenses – the CodeMeter license server only binds with Port 22350 if it has been configured to operate as a CodeMeter server on the network. In its basic configuration, the CodeMeter license server only binds with the localhost adapter. If it is operated in a (Docker) container, it would only receive queries from running applications and can respond either with a license present in the container (see above for the allowed types of CmActLicenses) or pass them on as a client to another CodeMeter license server on the network.
CodeMeter is versatile enough to cover a range of use cases in this manner. What they all have in common is that the container has to be operated in bridged mode – which is the standard setting out of the box.
"Protection Only“: The license can be activated in the container to serve purely as a means of encrypting and using applications. The container can be scaled easily e.g. to run the application in several installations at once.
"Licensing on the Host”: The license is activated on the host to restrict and keep check over the legitimate use of the application, e.g. as a CodeMeter SmartBind license. Each container has one CodeMeter license server running in client mode, which receives the requests from applications in the container and passes it on to the CodeMeter license server on the host. The server search list in the Docker network records the IP address of the host, e.g. 172.17.0.1, which will be permanent from a container perspective.
"Licensing via the Network”: This use case differs from the previous one only in the location of the server. It requires a CodeMeter license server operating on the network to provide the available licenses. In each separate container, a CodeMeter license server in client mode will again receive queries from applications in the container and hand them on to the network license server.