Reduce container escape risk in Polyaxon workloads

An AI execution platform needs to accommodate very different workloads: a reviewed training component, a notebook with interactive package installation, and an agent running generated code. Polyaxon lets teams manage those workloads through a common run model while assigning different execution settings, connections, and compute destinations.

Container escape risk belongs in that platform design. A container shares a kernel with its host, and a vulnerable runtime or excessive privileges can let code cross its intended boundary. Polyaxon gives platform teams a way to distribute and inspect workload configuration; the Kubernetes runtime, admission policies, node configuration, and identities determine the strength of the boundary.

Consider a coding agent that executes an uploaded repository. The useful outcome is a patch and a test report. It should not inherit the credentials, node placement, or filesystem access of a component that builds platform images.

Package a restricted execution preset

Use a scheduling preset to make the intended configuration reusable. The following example defines a preset file for an existing agent job:

runPatch:
  environment:
    serviceAccountName: agent-execution
    nodeSelector:
      workload-pool: agent-execution
    hostNetwork: false
    hostPID: false
    securityContext:
      runAsUser: 1000
      runAsGroup: 1000
      runAsNonRoot: true
  container:
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: [ALL]
    resources:
      requests:
        cpu: "1"
        memory: 1Gi
      limits:
        cpu: "2"
        memory: 2Gi
termination:
  timeout: 900
  maxRetries: 0

Save it as presets/agent-execution.yaml and apply it to a component that runs your reviewed execution wrapper:

polyaxon run -p agent-security -f agent-job.yaml -f presets/agent-execution.yaml

The service account and labeled nodes must already exist. The image must support the selected user and have explicitly provisioned writable locations for its workspace and temporary files. Check compatibility with the Polyaxon initializers and sidecars used by the component. A read-only root filesystem does not make mounted volumes read-only.

The environment specification documents pod settings, while the workload container accepts Kubernetes container settings. Keeping those levels separate matters: pod user identity and container privilege escalation controls are different fields.

Enforce the baseline at admission

Presets merge configuration into operations at compilation time. They make reviewed settings convenient to reuse, but their merge strategies and operation overrides mean they are not an immutable security policy. Polyaxon EE and Cloud support organization and project default presets; those defaults should be paired with cluster admission rules for requirements that users must not bypass.

For an untrusted execution namespace, enforce the restrictions that matter to your environment: privileged containers, host namespaces, host filesystem mounts, runtime sockets, and disallowed capabilities. Apply the policy to the complete resulting pod, including initialization and auxiliary containers. Review image-build workflows separately because their privileges and storage requirements can differ from those of the generated-code runner.

Give execution its own identity and compute destination

The custom service account workflow lets you select a Kubernetes identity per operation. Grant only the permissions required by that workload and its configured Polyaxon helpers. A pod with credentials that can administer the cluster can cause serious damage without escaping its container.

Review connections with the same discipline. Attach the repository and data access required by the task, and check the underlying credential's actual permissions. A connection name does not narrow a credential that already has access to an entire cloud account.

For higher-risk execution, Polyaxon commercial queues and compute agents can route work to a separate namespace or cluster. A node selector helps place work on a designated pool; exclusive placement also requires cluster controls that prevent other workloads from using that pool. Evaluate stronger runtimes or separate clusters when shared-kernel isolation does not meet the workload's threat model.

Connect containment evidence to the run

When a security check fails, investigators need the exact execution context. Retain the component revision, image digest, applied preset revision, connection names, and relevant cluster policy revision alongside a redacted report. Polyaxon's run lineage view connects tracked inputs, outputs, and dependent operations. Runtime security events still need to come from the cluster's monitoring tools and be correlated with the run.

Make containment qualification a reusable component: check prohibited mounts, identities, network destinations, and resource behavior in an approved environment, then store the results as artifacts. Repeat qualification when the node image, runtime, preset, or execution image changes. The resulting Polyaxon record gives reviewers concrete evidence for the configuration they are about to make available to their AI teams.