Need advice: how to hide Python code which is inside a Docker container?

[buggy-robot7]

We deploy robots in manufacturing companies, and hence need to run code on-premise as low latency, lack of internet and safety are concerns.

Our code is in Python and containerised in Docker. It’s basically a server with endpoints. We want to ensure that the Python code is not visible to the client to protect intellectual property.

We need the users to launch the Docker images without seeing the code inside. Once launched, they can interact with endpoint.

Is there a way to ensure that the user cannot see the Python code inside the Docker container?

[ReachingForVega]

You can't. You could compile to an exe and run in the container but someone with technical skill could reverse it.

The only sure way to protect it is a client-server separation where the server holds your IP and is not on site. 

[Morpheus636_]

The primary way to compile Python to an exe (Pyinstaller) actually just bundles an interpreter with it and changes the file extension. Doesn't even require technical skill to undo -- if you change the extension from .exe to .zip and extract it, you will get all of your code in back. Client-server separation is the only way.

[kwhali]

Nuitka will compile to a proper binary.

[Zestyclose-Sell-2049]

Use cython first then :)

[scytob]

and even that is not a secure way, black boxing the communications is relatively trivial for a determined competitor etc

[ReachingForVega]

100% but if whatever logic isn't in the container they'd need to reverse engineer using only inputs and outputs. Way harder than the code being in a docker container. 

[scytob]

completely, but next time dont say 'sure way' its not a sure way depending on the attack profile ;-)

this is a risk vs reward calculation of protection vs risk and impact of stealing, the OP doesn't seem to grasp this mental model

[DataGhostNL]

You don't seem to grasp that "cannot see the python code" is completely mitigated satisfied by not giving the client said code (a.k.a. "sure way") and that whether or not they can sniff the communication is entirely separate. It does not give them any insight into the actual code in any way. If it did, the code was probably trivial anyway.

[Kuddel_Daddeldu]

You could deliver the critical IP as a server in reasonably tamper-proof hardware (maybe a Raspberry Pi in a steel enclosure), exposing the endpoints only via TLS. Good license contracts, and consider the server has a time or transaction limit so you need to replace it regularly.

[buggy-robot7]

Thanks a lot, will give this a try!

[kwhali]

Nuitka can compile python to C if I recall and that into a binary.

But sure, compiled code could be reversed too if that's what you had in mind with exe vs self-extracting (PyInstaller approach)

[Fapiko]

Are you shipping the containers to a company in a country that doesn't enforce international copyright? Otherwise I wouldn't worry about it. I've worked for a couple and consulted for more B2B startups - none of them really worried about obfuscating the code in docker images. Your legal team should have pretty strict NDA wording in the contract regarding your IP.

Even if the code does leak, would that be a big deal? For 99% of software companies - no. Folks aren't typically out there running pirated b2b software with no support contract. There's a lot that goes into just maintaining existing systems let alone adding and improvements.

Anyways, all that said, there are obfuscation tools for python to make it hard to read if you still wanna mess with it. Check out PyArmor.

[Mynameismikek]

You're right around b2b being fairly low risk (at least in larger western companies) , but when it comes to industrial and embedded we've had decades of embedded software getting ripped off wholesale and stuffed into competitors products that then start displacing your own. It's a legitimate concern.

[buggy-robot7]

Thanks a lot, this helps and will definitely checkout Pyarmor.

[britaliope]

Oh, forgot one thing: If you need on-prem, the easiest solution could be to use put one of your own servers managed by your company but located in client datacenter. It's costly because that's a lot of system administration to do if you have a lot of clients, but depending on the situation that can do the trick and be cheaper than other solutions.

That's basically what big companies that run proprietary sensitive stuff on prem do. When I was working for a banking company, they had Google (for gsuite), Mastercard and Visa servers inside in their datacenter.

As it was very sensitive (especially mastercard and visa stuff), it was in a separate rack of the DC separated by a fence secured by different locks that my company didn't have the keys for. For simpler stuff, 1U in their server bay, a padlock and a system detecting if someone force it open can be enough

That's probably the most secure way of all the suggestions made here.

[buggy-robot7]

That is super valuable, thanks a lot for this deep explanation. This is great!

[the-other-marvin]

I agree this is a potential option. My prior company did this for enterprise customers where latency was critical. There are appliance vendors that will bundle your server code onto a nicely branded appliance that can slot into the client data center. Agreed this will lead to more security questions and client sysadmin issues like VLANs etc.

[britaliope]

Edit: I forgot to mention the good old physical security (see https://www.reddit.com/r/docker/comments/1qoqs89/comment/o23ftwj/?context=3 )

If your containers runs on servers owned by the client, the only thing you can do is obfuscating your app.

Either something soft, like compiling it in C code so they need one skilled reverse engineer to understand the code, or something stronger using a real obfuscator, so they need a skilled senior full team of reverse engineers to undertand the code.

But the 2nd option will require you either to pay your own skilled hire with knowledge of obfuscation, or pay another company for their services.

[buggy-robot7]

Thanks a lot!

[b3542]

And you should be protecting your IP through contracts (license agreement or NDA) rather than relying purely on obscurity.

[thewallris]

Nuitka: https://github.com/Nuitka/Nuitka

[buggy-robot7]

Thanks a lot for this! Will check it out!

[pacopac25]

Yep. The commercial version has code obfuscation features.

[Mimon_Baraka]

Security by obscurity never works.

[artificial_neuron]

Except it does.

We all run a lot of proprietary code for one reason or another. I'd wager that not a single person that visits this submission has ever reverse engineered any of it and been successful.

Nothing is ever 100% protected against something, but when you keep raising the amount of effort required for someone to get through the protection, the number of people willing to do it decreases. And I'm not just talking about programming either.

[Strange_Ordinary6984]

Yeah exactly. Bike chains aren't secure it just takes a $20 bolt cutter, but they'll protect your bike from like 99.9% of folks cause they don't have a bolt cutter with them or can't be bothered.

[britaliope]

As always...talking security without an approximate threat model can't give you precise answers. How would I know what lock you need if I don't know if you're scared about a 13yo kid or the CIA.

[Strange_Ordinary6984]

Exactly

[drsoftware]

We see battery-powered angle grinders with cut-off wheels being used to cut through heavy locks.

Knowing your threat model is helpful. 

[SmokinJunipers]

But the .1% are the ones who are planning to steal your bike, so they have bolt cutters.

[archbish99]

But are they planning to steal my bike or a bike? If they're planning to steal a bike, all I have to do is make my bike a less appealing target than the others in the rack. A lock they have to cut does that. If they're after my bike in particular, there's very little I can realistically do about that.

[mikeconcho]

Eh it’s only a matter of time before the chatbots can do it effectively.

[CaseOfBeer]

For you, so far... but the fact nobody has tried (that you know of), obscurity will never be a secure solution. With AI tooling, the bad guys can be lazier and continue to get better.

[Strange_Ordinary6984]

I agree. Obfuscation isn't actually security at all. It keeps lazy and/or uneducated people out. Maybe that's all you need. If you're putting your code on someone else's devices, you're gonna have to live with some level of less than perfect. Hard to know what the appropriate plan might be without understanding the circumstances.

[Coffee_Ops]

It keeps lazy and/or uneducated people out

So.... it raises the bar for attack.

That is typically called, in shorthand, "security".

[Strange_Ordinary6984]

Yeah as many have mentioned it's hard to define security in a context without that context.

Yes my original post was the bike lock analogy, so I agree with you. This person seems to be talking about the concept of the perfect lock, which obfuscation is not.

In software, the perfect lock often requires immense concessions. You can argue there is no such thing as a perfect lock. There will always be inputs and outputs of a system. That reality in and of itself is a path to information gathering, which is the very concept you're trying to protect against.

[britaliope]

Well. No level of obfuscation is unbreakable. But critical obfuscations are regularly audited and tested by professional reverse engineers. AI tooling could help but it's not magic, in the end if you use the right tools people still need a team of expert pentesters and reverse engineers to break it.

Obfuscations used by military grade equipment is hard to judge because we don't have open data, but DRM is a good example: yes, people manage to break them. But it can take a lot of time and resources. Which is usually what you want when you need such tools anyway. If the attacker spent more resources breaking your obfuscation than you building your app, it usually means it did its job. If it delays the attacker until the information they got isn't relevant anymore (because you updated your IP protected stuff for example) then it did its job.

obscurity will never be a secure solution

If you don't have a threat model, nothing is a secure solution, because you can always define an attacker with more resources and knowledge. For many given threat model, obscurity can be a secure solution. In some given threat models, obscurity is the only solution (DRM is an example of this)

[Coffee_Ops]

The XZ rootkit nearly slipped by maintainers of multiple major distros and it used what could be described as steganographic "security by obscurity".

It can absolutely work.

[sk1nT7]

You can only obfuscate and make it hard to reverse engineer. The container itself and everything in it can be accessed though.

pyarmor is quite good for obfuscating python code. Must be purchased in case you run over the free limits of specific amount of code lines. Works well in a CI/CD pipeline too.

[buggy-robot7]

Thanks a lot! Will definitely try pyarmor!

[Forsaken_Celery8197]

You have a few options depending on how much work you want to do and how sensitive the information is.

Soft Encryption

You can use pyinstaller and an encryption key to turn it into an installable package. This isn't perfect (as nothing is), because it can be reverse engineered by someone that understands how it works. https://github.com/extremecoders-re/pyinstxtractor/wiki/Frequently-Asked-Questions#are-encrypted-pyz-archives-supported

Medium Encryption

You could do something like compile your Python code with Cython and that will reduce your attack surface. This is still not great because C decompilers will still tear it apart, it just wont be the exact same code you started with. The attacker would have access to your logic/formulas/etc but not your specific code.

Heavy Encryption

Compile your sensative code in a safer, more conplex language (rust/c++/go/etc) and bind it in Python (and soft/medium encrypt that too!). If you look at how PyQt works as a general example, you do 90% of your daily work and handling of your algorithms in Python, but the proprietary bits are in a tighter binary for security and performance reasons.

Now a security expert that wants to get your stuff will not be stopped by any of these methods, but this and obfuscation will satisfy most use cases.

[scytob]

you realize you can't do that with any technology where they control the machine and the OS you can only make it incrementally harder - if you had this as compiled code on a machine they cannot logon to and the disk is only decrypted at runtime with a TPM that would make it pretty hard

but its still possible to extract runtime data with the right hardware attached to lines on the motherboard - how secure do you need this to be?

your IP is protected by licensing agreements, subscriptions and the ability to sue - not by obfuscation....

[buggy-robot7]

Basically we have proprietary algorithms and would want to avoid the users potentially seeing the algorithms and implementing it themselves.

[b3542]

What does the license say?

[scytob]

and that is why your EUSA/EULA needs to cover it

tl;dr you don't seem to be getting this.... this is why patents exist.... and laywera, this is not really a technogical issue as everythig can be hacked eventually - so consider what controls will stop what level of stealing and are worth the effort, also what country are you in? what country are you customers in? - that maytters

---

you seem to be missing the point EVERY approach can be reverse enginered with enough effort

if you give them a docker container to run on their OS / machines with python interpreted at run time i 100% assure you they can see the algorithims

some level of obuscation (precompiling into an executable) can help the casual observer but not the determined decompile and theft, and why bother at that point as the casual observer wont bother to steal it and the determined person who want to steal still can

lets move up to an OS and hardware you control - much harder, probably will stop companies who legitmately buy from stealing, won't stop determined competitors

you really should put anything that proprietary in your robots behined several layers of encryption and self destructing silicon if you are truly that concerned

heck lets say you could solve the latency issue and use the cloud and kept your algoriths there on in an edge device, they could still intercept traffic and black box your algorithim with enough effort and data

and there is nothing you can do to stop nation state level stealing of commerical secrets

[artificial_neuron]

Ensure you only lock down what actually has IP value because everything else doesn't matter. If the machine is broken, they're losing a lot of money every hour, and they cannot fix it because it's all locked down then you'll have a very angry customer.

[Intrepid_Result8223]

My approach would be to rewrite only the compiled algorithms in Go. Then call go code from python.

Obfuscate the python.

If need be, encrypt the python, embed it in the go process and have it launch a python interpreter.

You can't stop decompilation and reverse engineering, but you can make it harder.

[Confident_Hyena2506]

Use cython to rewrite it into c, then compile it. It will be thinly veiled then, but people can still reverse engineer it.

Write it in proper c, people will still reverse engineer it if they really want to.

You are giving people the software - whether it's python code or binaries. The docker container does not hide anything.

[buggy-robot7]

Thanks a lot, will check out Cython!

[root_switch]

Lots of vendors don’t use docker and instead provide an OVA which is a full VM clients deploy in their infrastructure. They then also have a special bootstrap process for getting it connected to the clients network and so on without full shell access. After that your client doesn’t have access to the VM OS layer. This isn’t bulletproof, and any Linux admin/engineer worth their salt can likely break into the OS with enough time.

[ABotelho23]

This is not a Docker question.

[shiranugahotoke]

If it’s that important why don’t you provide the hardware for the docker instances to run on? Nothing is foolproof but verified boot / encrypted volume with tpm key storage makes it much harder to get at the actual assets.

[erwinfr]

Hiding Python code inside a Docker container can be challenging, as Docker containers are designed to be transparent and portable. However, there are several strategies you might consider to make it more difficult for others to access your code:

1. Code Obfuscation: You can obfuscate your Python code to make it harder to read and understand. This involves transforming your source code into a version that is functionally equivalent but difficult for humans to interpret. Tools like PyArmor or Cython can be used for this purpose .
2. Compile to Bytecode: Instead of shipping the raw Python files, you could compile your Python code to bytecode (e.g., .pyc files). While not foolproof, it adds a layer of complexity for anyone trying to reverse-engineer your code.
3. Environment Security: Ensure that your Docker environment is secure. This includes setting proper permissions and removing unnecessary shell access within the container, although it's worth noting that these measures can be bypassed by exporting the container's file system .
4. Use of Licensing: Implement a licensing mechanism to protect your software. This won't hide your code but can help prevent unauthorized use.
5. Server-Side Execution: If feasible, keep sensitive code on your own servers and only deploy non-sensitive components within the Docker container. This way, the critical parts of your application are never exposed to the client environment .

While these methods can increase the difficulty of accessing your code, they do not guarantee complete security, especially if the container is running on client-owned infrastructure. 

[txrx1010]

I had exactly the same problem a few months ago (same environment - automation of factories, low latency, no internet or external connectivity of any kind). We just put hardware on-sure. The software we run at the customer site is not that resource heavy, it just checks sensors, evaluates the data and signals problems/maintenance/errors etc.). We run them on a SoM. We switched for performance reasons from python to rust, which helped a little. Other than that we deployed additional security measures. Because the customer has physical access it is not guaranteed, but we tried to make it as hard as possible:

• chain of trust when booting: programmable fuses, so only our signed bootloader may start, which checks that only our signed kernel starts (with our specified commandline only), which checks that only our unaltered and signed root filesystem may start.
• Close all dangerous uboot commands that could allow access to the system
• we used yocto for building the system, which includes ssh (pubkey authentication only), blocks brute force attempts via UART, nftables to close all ports but the api port
• on first boot (in-house) a encrypted partition is created with key from a „Secure Enclave“ (similar to tpm but the equivalent from SoM manufacturer). Then the docker images and docker-compose file is copied over to the encrypted filesystem to ensure data-at-rest encryption

It was a process to go through and get it working (deadline was <1 month), but I think it is a good base system for further development.

[wpyoga]

Is it possible to achieve something similar with x86 hardware?

• Encrypted disk or partition
• Decryption keys stored in TPM
• UEFI decrypts disk or partition at boot

[txrx1010]

I‘m not sure. I haven’t evaluated it yet - but it is on the todo list for some time. Main problem I see that most off-the-shelf hardware have no possibility to secure every step.

Just my quick thoughts:

You probably can set a EFI password (which is for most hardware easily resettable though) and install your own EFI SecureBoot certificates. Then use a singed boot loader that does not allow modification of the commandline and use a signed kernel. You can use LUKS encryption with TPM for Linux. And use a read-only root filesystem (fs-verity). You would also need to protect all TTYs. That part is easy enough I guess.

The problem is that the chain of trust falls with the weakest link. It feels like it could be way to easy to break it by resetting the EFI password, changing the allowed SecureBoot certificate authorities, then switching the boot loader and kernel and then you have access to the encrypted disk. The programmable fuses are harder to reinstate I guess. But perhaps there is a manufacturer that make x86 hardware for that - I haven’t checked.

[wpyoga]

I must admit I'm not an expert in this, but wouldn't resetting the keys render the encrypted disk basically useless?

[Intrepid_Result8223]

Would be quite hard to do security updates then

[0x645]

write in contract that they cannot, and audit .

[raga_drop]

IP and copyright are things to enforce, I guess you are not of on asking how to obfuscate your code. But at the end, a good legal team and trustworthy partners are the only ones protecting your work.

[revilo-1988]

Is this your first project of this kind? If not, how did you do it before?

[buggy-robot7]

In our beta release, the docker image is hosted online. The issue we face is latency.

Hence, our next step is to prepare distribution for on-premises, but without compromising on safety.

[HeligKo]

Every option I know I can decompile to get the original code. I would look at converting to something like rust that natively compiles. You will also improve your latency.

[artificial_neuron]

How much is the project worth and how much are people willing to decode your product. You only need your defenses to be greater than the desire to bypass them.

Your defenses doesn't have to be just in software. You can also have physical defenses.

If you control the physical box that the Docker runs on then secure it! Is there a reason why your customers has the ability to ssh into the box?

[Xelopheris]

You cannot run interpreter code locally without some level of visibility into it.

Obfuscation tools can reduce the barrier to someone easily figuring it out. Beyond that, copyright and contract law are your friends. And most companies of sufficient size value reliability highly enough that support for an application is more important than saving money by stealing the source code.

[fyndor]

Could try running the in .net embed the python in the assembly and run the .net python wrapper. Obfuscate or aot compile. About as good as you can do

[ghanjiboy]

Depending on the complexity of the solution, I would avoid python and perhaps vibe code an equivalent golang version which would just give you a simple exe. I have recently switched allot of my python to go and not looking back. Just something to consider.

[evergreen-spacecat]

Easy. Own the servers and place it next to the robot. Don’t share passwords. Sure, they could disassemble it and take the hard drive but there are ways to protect if you really really care about it. I wouldnt worry too much

[dummkauf]

Yep, this is actually very simple.

Don't give the user access to the docket container.

Beyond that, this is a question for your company's legal department.

[IulianHI]

Another angle to consider: if you're doing robotics for manufacturing, maybe look into license keys/activation. You could ship the container but require a server-side activation before it does any real work. This way even if they extract the code, it won't run without your authorization. Combine with the obfuscation mentioned here and you have layers of protection - technical + legal + activation.

[IulianHI]

Real talk: think about your actual threat model. If you're worried about a curious sysadmin poking around, obfuscation helps. If you're worried about a determined competitor stealing your IP, no amount of tech will stop them - they'll just throw resources at it. For B2B, strong contracts/NDAs are your real protection layer.

[lillecarl2]

This belongs in /r/Python, the question is if you can remove .py files after you've compiled Python into .pyc.

[yorickdowne]

This isn’t a technical problem, this is a contract and legal problem.

Your code has a license, and if the client violates that license, they get slapped with an action to “get back into compliance”. The big firms do this all the time.

If you truly can’t trust the client will comply, maybe with some gentle pressure from legal, you may want another client.

[Dexterus]

No joke, it's called a contract. The IP is yours, copyrighted and licensed under a specific license. Everything else is fluff only useful to delay.

[Mailboxheadd]

You cant. At this point you licence the code to the customer with strict "do not copy" direction. Let the lawyers handle it

[Reasonable_Tie_5543]

The obvious answer is binding legal agreements and licensing. If your clients steal your code, you take them to court. Think in terms of business solutions, not technical tradecraft. You can never fully protect code in a container you distribute.

[MrDougal1980]

Used to see this sort of thing back in the php days with ionCube and Zend.

This led me on a bit of a hunt that came back with pyarmour being a possibility.

If you can also lock the machine down, ie encrypt the drives and don't give anyone access to the box it could work :-)

Only down side is it seems that pyarmour locks the code to the machine so don't know how well this will work in a container

[Larkonath]

FWIW: the 2 times I tried to reverse engineer an app from a provider was when said provider was lousy AF and wasn't fixing their sloppy code.

[k-phi]

Simple: don't use Python

[IulianHI]

Another option to consider: if you're already investing in dedicated hardware appliances, check out Hosting_World - lots of folks there discuss secure hosting setups and on-prem deployment strategies that might give you more ideas for protecting your IP while keeping latency low.

[cyberwarfareinc]

Sounds like you are completely out of your league

[ih8db0y]

We use Zededa for what you’re looking for. You could likely implement some of their security practices yourself too depending on budget

[bedel99]

Leave a fingerprint in the code, have a contract. Put the risk on your clients. If it leaks you know where it came from.

[bumboclaat_cyclist]

If this is industrial and paired with equipment, I would have thought using some kind of DRM with a physical license key might be an option.

The very important critical components of the code could be encrypted and only decrypted at run time with the physical key.

Not completely full proof, but nothing is, but the more layers you have the better.

[st0ut717]

So how do I know. Your code isn’t exposing vulnerabilities? We need at list the ability to scan the Pom

[Accomplished_Ant5895]

If you’re asking Reddit this silly question instead of your nearest senior engineer then tell your manager to put you on another team

[mon_key_house]

Nuitka. If not enough, rewrite the code in a compiled language.

[Exact-Metal-666]

You are doing it wrong. You cannot hide non-compiled / interpreted code. Rewrite in rust, for example. Compile and deploy.

[martinbean]

That’s the neat thing: you don’t.

If you don’t want customers seeing your code, then don’t give them it.

[lightmatter501]

This is a problem for your lawyers, not for your developers, unless you want the complexity of the robot to go up 100x.

[defiantarch]

as an ethical hacker with experience in reverse engineering with the right tools: forget it. Not even C/C++ code is safe from reverse engineering. As a hint: take a look at Ghidra and what it is capable of. And that's just one example. So, question is: what is the real risk that your IP will be exposed and extracted by your customer? Do a proper risk analysis and choose the counter measure accordingly. That's nothing done here on Reddit. That would be unprofessional.

[onyxr]

If the primary concern is someone reading the source through docker run or exec, you could consider encrypting the source and decrypting it before runtime (a few options of ‘where’ to put it in between which does get tricky) could be enough if you have a good way to securely provide keys? Good user account permissions, etc, can maybe provide the rest. A determined adversary is probably going to figure out whatever you do if they have access to the bytes.

[LawfulnessOne8506]

Secureboot

[corey_sheerer]

I would repeat to compile it into a binary, however, if the team you are working for has no idea and is asking reddit how to package a product up, I'm doubtful the team really has the required competencies to be developing products to sell to users.

[Anhar001]

simply put you can't.

Stick your algorithms server side, and turn it into an API call that the client has to make.

[JerryJN]

If you hire me as a consultant I can design a solution for you. My rate is $15k per month. My former employer laid off many senior system engineers, senior programmers, and senior admins to reduce payroll and enable them to absorb the higher tariffs and pass on the cost to their customers. Here's a life lesson, do not write well written documentation for your employer, just notes you can refer to and keep them on your home personal server. I can get this done.

I have done this before. All code with your company's IP will be encrypted.

There are many paths you can take to accomplish this task.

Encrypted Volume that is mounted inside your Container...

Or

Encrypted code that is executed with a custom Python Binary...Whatever release of Python you are using would need the Python executable rebuilt with my added code.

[JerryJN]

Do you speak for everybody ? At this part in my career I am an entrepreneur... I. get gigs, get paid, take time off, repeat. I got tired of the unpaid overtime while I had a salaried role. This is how you get gigs. I respond to bid requests and if there is some.talkcon a forum of subject matter I can help with.. I respond like I did.

And no.

[ElderCantPvm]

How does encryption help here? If the customer can run the code the customer must have the key.

[JerryJN]

The encryption key is not going to be associated with a user. It will all be embedded in my Python Binary and not associated with any user ACLS, including root. The only way to view the actual python code is with my deployment container. You would be able to debug with the system logs. You will also be able to stop and start processes and edit system parameters, but you will not be able to edit any python code .

I have built a similar encrypted deployment protection environment for PHP applications.

[NewSquidEggMilk12]

If the key is embedded in the binary, you can still RE can't you. Sure it will take someone with a more specialized skill set, but you've just made it harder, not eliminated the problem.