CDX-301f · Module 2

Service Mesh Integration

3 min read

Service mesh integration connects Codex Cloud microVMs to your organization's internal service infrastructure. In a service mesh architecture (Istio, Linkerd, Consul Connect), services communicate through sidecar proxies that handle authentication, authorization, load balancing, and observability. Integrating Codex microVMs into this mesh means running a sidecar proxy inside or alongside each microVM, enrolling it in the mesh's identity system (mTLS certificates), and configuring routing rules that control which internal services the sandbox can reach.

Mesh integration is the most complex networking configuration for Codex Cloud — and the most powerful. Once a microVM is enrolled in the mesh, it can access internal services (staging APIs, test databases, mock servers) using the same service discovery and authentication mechanisms as your production workloads. The agent can run integration tests against real internal services without exposing those services to the public internet. The mesh's authorization policies replace the simple domain allowlist with fine-grained service-to-service access control.

# Service mesh integration architecture

MicroVM
├── Agent process (Codex)
├── Sidecar proxy (Envoy/Linkerd)
│   ├── mTLS certificate (auto-rotated)
│   ├── Service discovery (DNS/API)
│   └── Authorization policy
└── Network namespace (shared with sidecar)

# Mesh authorization policy
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: codex-sandbox-policy
spec:
  selector:
    matchLabels:
      app: codex-sandbox
  rules:
    - to:
        - operation:
            methods: ["GET"]           # Read-only
            paths: ["/api/v2/*"]       # Specific API paths
      from:
        - source:
            principals: ["codex-sa"]   # Codex service account

# What mesh integration enables
- Internal API access with mTLS (no API keys needed)
- Fine-grained path-level authorization
- Distributed tracing across sandbox → service calls
- Traffic mirroring for shadow testing

Do This

  • Use mesh authorization policies to restrict Codex to read-only access on specific API paths
  • Enable distributed tracing so sandbox API calls appear in your observability platform
  • Use short-lived mTLS certificates that auto-rotate — the microVM lifecycle is minutes, not days

Avoid This

  • Give the Codex sidecar the same mesh permissions as production services
  • Skip authorization policies because "the sandbox is isolated" — network access is a separate concern
  • Run mesh integration without monitoring — invisible API calls from sandboxes can affect service load