I'm designing an on-premises or bring-your-own-cloud deployment, but I don't want to place my services directly inside a customer-controlled VPC where someone with root or administrator access could inspect the containers, binaries, or host filesystem. This applies whether the software runs in Docker on a VM or in a Kubernetes cluster.
If I don't use a strict control-plane/data-plane split—and the customer's data must remain inside their own environment—what practical options exist for protecting the implementation? Would I need to build a hardened OS image with measured boot, attestation, and staged key verification, or consider technologies such as confidential VMs, Nitro Enclaves, or GPU confidential computing? How much protection can these approaches realistically provide against a customer who controls the underlying infrastructure?
4 Answers
It may be more productive to treat the deployed software as something that can eventually be analyzed and focus on protecting the parts that are hardest to reproduce: proprietary data, hosted services, operational know-how, frequent updates, support, and the accumulated expertise behind the product. Legal agreements and licensing controls can supplement that strategy, but neither contracts nor packaging a program as a binary makes the code impossible to recover.
Confidential-computing features, measured boot, attestation, and hardware-backed key release can reduce the customer’s ability to inspect code while it is running, especially against a cloud or host administrator. But they come with significant implementation and operational complexity, and they don’t eliminate every attack path. You also need to verify exactly which actors the hardware and cloud provider trust model excludes.
If the customer’s data truly cannot leave their environment, one architectural option is to keep the sensitive logic in a service you operate and expose only a private, tightly controlled interface. However, VPNs, private connectivity, cross-account peering, or similar designs only work if the customer accepts that model. If the entire workload must execute in their VPC, the protection problem becomes much harder.
You generally can’t fully protect software that runs in infrastructure controlled by the customer. With sufficient privileges, they may be able to inspect memory, trace execution, extract artifacts, or reverse-engineer the binaries. Compilation and obfuscation can raise the effort, but they aren’t a complete security boundary.
A contract can still help with unauthorized copying or reverse engineering, but it doesn’t technically prevent an administrator from examining software deployed in their own environment.
That approach doesn’t fit cases where policy requires all processing and data access to remain inside the customer’s VPC, so the deployment constraints need to be clarified first.