Unique AI Documentation

Self-Hosting Conduct

2 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, and SandboxWarmPool. 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.org and files.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?

  • Can the client enforce L7-capable network policy, including DNS and FQDN controls?

  • Can the client approve custom CRD installation?

  • Can the client run a sandbox controller/operator?

  • Can the client allow narrow RBAC changes for Conduct?

  • Can the client allow package downloads from approved registries or mirrors?

How Unique SaaS solves the challenges

Last updated