A Supply Chain the Customer Can Gate

The most privileged action a vendor takes in BYOC is running code inside the customer's account. Every container image, Helm chart, and infrastructure module is an act of supply chain, and zero trust requires that the customer can inspect, gate, and veto that supply chain with the controls they already trust. That requirement fixes the architecture: artifacts must flow through infrastructure the customer owns before they run.

The mechanism is registry mirroring into the customer's environment. Before workloads deploy, your control plane copies the full image inventory from your source registries into a registry the customer designates: their ECR, their Artifact Registry, their Harbor, any OCI registry they operate. Workloads then pull only from that registry at runtime. Make the inventory self-describing by discovering it from chart metadata annotations, so the customer always sees the complete set even as your product adds components. Once images live in the customer's registry, the customer's entire supply-chain apparatus applies to your software automatically: their vulnerability scanning, their signature and provenance policies, their admission controllers, their promotion workflows. Your software clears the same bar as code the customer wrote.

Delivery modes follow the customer's connectivity posture (Commandment II). In connected environments, your control plane syncs images at install and upgrade time, a pull-then-push the customer can observe and gate. For restricted and air-gapped environments, embed images into a self-contained installer at build time: charts, images, and lifecycle scripts in one artifact that installs with zero internet access and pushes images into the isolated registry from inside. Terraform modules and other artifacts follow the same pattern, staged in per-account object storage where the customer can inspect them before use. Run validation hooks before anything installs, so the customer can enforce preconditions on their own cluster.

Be precise about the control plane's role. It holds the source-of-truth artifact manifest, publishes signed releases, and orchestrates the mirror. It must never sit on the runtime pull path, and it must never hold a path by which vendor artifacts reach nodes without clearing the customer's admission controls. The registry, the scanners, the signing policy, and the admission decision all live in the customer account. If your control plane goes down, running workloads keep pulling from the customer's registry unaffected.

Mirroring places enforcement in the customer's hands, and the customer still needs vendor-side integrity to enforce against. Pin digests, sign your images, and publish SBOMs, and tell customers to demand the same from every vendor, including you. The durable win of this architecture is placement: because the registry belongs to the customer, nothing reaches a node without passing through a chokepoint the customer controls.