Unique AI Documentation

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 the agent-sandbox custom resources: Sandbox (agents.x-k8s.io) plus SandboxClaim, SandboxTemplate, and SandboxWarmPool (extensions.agents.x-k8s.io). 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. The controller ships with a sandbox router service through which the platform reaches sandbox workloads. 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 / files.pythonhosted.org, registry.npmjs.org, and Debian apt mirrors (deb.debian.org, security.debian.org), or to an internal mirror.

  • A ReadWriteMany-capable StorageClass must be available. Conduct's checkpoint and skill-cache storage (sbx-storage) mounts a shared RWX volume (~100Gi). Performance requirements are modest: the workload is sequential read/write of zipped checkpoint archives, not small random I/O — a standard-tier file share sustaining ~1,000 IOPS and ~60–100 MiB/s is sufficient (Unique SaaS runs this on Azure Files Standard; Premium/SSD-backed shares are not needed). ¹

    ¹ It is technically possible to deploy Conduct without sbx-storage, but this comes with a heavy performance penalty.

  • Optional: KEDA for warm-pool autoscaling (via the SandboxWarmPool scale subresource) and Prometheus Operator (PodMonitor / PrometheusRule) for sandbox metrics and alerts.

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.

  • Can the client provide a ReadWriteMany storage class?

    • Without it: technically possible, but with a heavy performance penalty.

    • Alternative: Any RWX-capable CSI driver (Azure Files, NFS, CephFS); or a single-replica ReadWriteOnce deployment with reduced availability.

How Unique SaaS solves the challenges

Last updated