Self-Hosting Conduct
3 min read
This page lists the platform requirements for running Conduct securely in a self-hosted Kubernetes environment. It does not describe the Conduct runtime architecture; this is currently being documented and will be linked here once available.
Hard requirement: Conduct needs permission to install and operate sandbox infrastructure in the cluster. If the client cannot allow CRDs, an operator/controller, kernel-isolated workloads, and L7-capable network policy enforcement, Conduct cannot run securely.
Required Cluster Capabilities
Kernel-isolated pods must be supported. Sandbox workloads need a kernel-backed runtime class, for example Kata Containers. Shared-kernel isolation alone is not enough for untrusted code execution.
L7-capable network policy must be enforced by the cluster. Raw Kubernetes NetworkPolicy is not enough. Conduct needs a CNI that can enforce DNS and FQDN-aware egress controls, guard DNS resolution, and restrict sandbox traffic beyond IP and port rules. Cilium or an equivalent L7-capable policy engine is required.
Custom CRDs must be allowed. Conduct depends on sandbox custom resources such as
SandboxClaim,SandboxTemplate, andSandboxWarmPool. These resources are not part of Kubernetes and must be installed in the client cluster.A sandbox operator/controller must be allowed. The controller watches the sandbox CRDs and manages sandbox allocation. Environments that forbid custom controllers cannot support Conduct.
Kubernetes RBAC changes must be allowed. Conduct needs narrow permissions for the orchestrator and sandbox controller. A cluster policy that blocks all new roles, role bindings, or service accounts blocks Conduct.
Package registry access must be controlled but possible. If agents install dependencies, the sandbox path needs approved access to package sources such as
pypi.organdfiles.pythonhosted.org, or to an internal mirror.
These capabilities are additive to an already running Unique installation on Kubernetes.
Security Baseline
No unsupported runtime fallback. If VM isolation is unavailable, do not silently run Conduct sandboxes as normal application pods.
No open sandbox egress. Outbound access must be limited with L7-aware policy: DNS must be constrained, FQDNs must be allow-listed, and package registry access must go only to approved registries or mirrors.
No broad cluster-admin permissions. RBAC should be scoped to the sandbox resources and namespaces Conduct manages.
No platform secrets inside sandbox pods. Sandboxes run untrusted user-driven code and must not receive broad service credentials.
Client Decision Points
Can the client provide kernel-isolated Kubernetes nodes and a matching runtime class?
Without it: Conduct could technically execute in shared-kernel pods, but this creates unacceptable risk and is unsupported from Unique AI AG.
Alternative: None providing equivalent security.
Can the client enforce L7-capable network policy, including DNS and FQDN controls?
Without it: Conduct could technically execute, but sandbox egress cannot be securely controlled. This is high-risk and unsupported by Unique AG.
Alternative: Any equivalent L7-capable policy engine.
Can the client approve custom CRD installation?
Without it: Conduct’s current implementation cannot manage its sandbox resources and will not function.
Alternative: None without custom pro-rata billed re-implementation and running operations and maintenance fee.
Can the client run a sandbox controller/operator?
Without it: Sandbox allocation, reconciliation, warm pools, and cleanup will not function.
Alternative: None without custom pro-rata billed re-implementation and running operations and maintenance fee.
Can the client allow narrow RBAC changes for Conduct?
Without it: Conduct components cannot manage their required Kubernetes resources and will not function.
Alternative: Pre-provisioned least-privilege roles, bindings, and service accounts with equivalent permissions.
Can the client allow package downloads from approved registries or mirrors?
Without it: Conduct can run, but agents cannot install runtime dependencies.
Alternatives: Use an approved internal mirror or preinstall all dependencies in sandbox images which drastically reduces the agents core strength – flexibility.
How Unique SaaS solves the challenges
AKS Pod Sandboxing → https://learn.microsoft.com/en-us/azure/aks/use-pod-sandboxing
Azure CNI powered by Cilium → https://learn.microsoft.com/en-us/azure/aks/azure-cni-powered-by-cilium
Public PyPi access via the Sandbox Gateway → https://unique-ch.atlassian.net/wiki/spaces/sdv2/pages/2258239534/Sandbox+Service+Code+Execution+Infrastructure#Sandbox-Network-%26-Identity-Controls