If the user has a root, or he can use his own kernel (or even kernel modules), he can do anything - flush the memory, stop the process, apply a debugger - start reverse engineering. If the user has access to the equipment, he can also get a root or custom kernel. The only way to protect the user from the user is to use good DRM, for example, using TPM (Trusted Platform Module) or ARM TrustZone. SecureBoot will not fully protect your soft (on x86 it can usually be disabled). In another embodiment, equipment protected from unauthorized access is used ( http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/what-is-tamper-resistant-hardware.htm ), for example, that It is used to store basic encryption keys (for processing PIN codes) in banks ( http://en.wikipedia.org/wiki/Hardware_security_module ), but this equipment has a very high cost.
It is known that Docker does not protect the code from the user: fooobar.com/questions/277635 / ... -
The root user on the host computer (where the docker daemon is running) has full access to all processes running on the host. This means that the person who controls the main machine can always access the RAM of the application, as well as the file system. This makes it impossible to hide the key to decrypt the file system or protect RAM from debugging.
Any user who can deploy a docker container (a user from the docker group) has full access to the fs container, has root access to the container processes and can debug them and unload their memory. https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful
Only trusted users are allowed to control the docker daemon
http://docs.docker.com/articles/security/#docker-daemon-attack-surface
Docker allows you to share a directory between the Docker host and the guest container; and this allows you to do this without restricting access rights to the container.
So, Docker does not provide additional protection for your code from the user ; we can treat it like other packaging systems like rpm and deb. Rpm and deb let you pack your code into separate files and a list of dependencies, while dockers pack your code and dependencies into a single file.
Our solution is hosted on our client cloud server, so they have access to both the root and the hardware. However, we have two advantages: 1) we have access to a secure port, which we can use to send tokens to decrypt the code and check for suspicious actions; 2) we can perform manual installation (key in the token during installation)
You can protect only your own code if it works on your hardware (disable all NSA / IntelME / IPMI / UEFI for your own hardware). If the user runs your code on his equipment, he will have all the binary files and will be able to dump memory (after receiving a token from you).
Virtualization on its hardware will not give your code extra protection.
"Secure port" means SSL / TLS / SSH? It is protected only to protect data when it is sent over the network; both endpoints will have data in a simple, unencrypted form.
Manual installation will not help protect the code after exiting the data center.
I think you can buy some common software protection solution, like flexlm, perhaps with some hardware tokens needed to run the software. But any defense can be cracked, early (cheaper) cracking will be easier, and modern (more expensive) defense will be more difficult to crack.
You can also run a piece of software on your servers; this part will not be broken.
or use hardware protection against unauthorized access, if necessary.
You cannot use equipment to protect against unauthorized access if the user server does not have such equipment. And it is very expensive.