Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Infrastructure & Perimeter Isolation

The organizational assistant operates inside a dedicated, isolated perimeter provisioned within the customer’s chosen cloud tenant. Network exposure, identity management, and container execution follow strict defense-in-depth principles.


1. Perimeter Isolation & Network Topology

graph LR
    subgraph PublicInternet [Public Internet]
        User[Corporate User]
        API[Workspace API Gateway]
    end

    subgraph VPC [Private Cloud VPC / Internal Network]
        CloudNAT[Cloud NAT Gateway]
        IAP[Identity-Aware Proxy: Port 22]

        subgraph PrivateVM [Private Dedicated VM: No Public IP]
            Host[Linux Host OS]
            Container[Quadlet Container: Unprivileged User]
        end
    end

    User -->|TLS 1.3 HTTPS| API
    API -->|Encrypted Pub/Sub| PrivateVM
    IAP -.->|Encrypted SSH Tunnel| PrivateVM
    PrivateVM -->|Egress via NAT| CloudNAT
    CloudNAT -->|Outbound HTTPS| PublicInternet

Zero Public IP Addresses

  • Host compute instances are provisioned with --no-address. No public IPv4 or IPv6 addresses are allocated or bound to network interfaces.
  • Inbound connections from the public internet are disabled at the VPC network firewall level.

Administrative Access via Identity-Aware Proxy (IAP)

  • Administrative access operates exclusively through Google Cloud Identity-Aware Proxy (IAP) tunnels (--tunnel-through-iap).
  • No SSH ports are exposed to the internet.
  • Connection requires enterprise identity authentication, Multi-Factor Authentication (MFA), and explicit IAM role assignment (roles/iap.tunnelResourceAccessor).

Outbound Traffic via Cloud NAT

  • External API calls (to Google Workspace APIs, Pub/Sub endpoints, and inference models) route through a dedicated Google Cloud NAT gateway.
  • The Cloud NAT gateway provides controlled, monitored outbound internet access without exposing the VM to inbound traffic.

2. Compute Runtime & Container Sandboxing

graph TD
    subgraph VMHost [Compute Engine Host Instance]
        subgraph UserSpace [Unprivileged User Context: uid 1000]
            Quadlet[systemd Quadlet Service Manager]
            subgraph ContainerSandbox [Rootless Podman Sandbox]
                direction TB
                App[Org Assistant Process]
                Tmpfs[(In-Memory tmpfs: /tmp)]
                ReadOnlyFS[Read-Only Container Rootfs]
            end
        end
    end

    Quadlet -->|Manages Lifecycle| ContainerSandbox
    App -->|Writes Ephemeral Cache| Tmpfs
  1. Rootless Container Execution: The core assistant daemon runs under an unprivileged user context (org-assistant, UID 1000) using systemd Quadlet and Podman.
  2. Read-Only Root Filesystem: Container root filesystems are mounted read-only wherever supported by workload constraints.
  3. In-Memory Ephemeral Storage: Scratch data and session caches reside on volatile tmpfs mounts that clear immediately upon process termination.
  4. Process Isolation: The container operates within separate mount, network, PID, and IPC namespaces.

3. Cryptographic Secret Management

  • Secrets at Rest: All client profile configurations (encrypted.config.json and encrypted.clients.json) are encrypted using Mozilla SOPS backed by Google Cloud KMS or Age keys.
  • Zero Environment Variables for Operational Secrets: Operational tasks, provisioning scripts, and container definitions never pass API tokens or private credentials via ambient environment variables.
  • In-Memory Provisioning: Decrypted configuration blocks stream directly into the isolated runtime memory or transient tmpfs mounts across encrypted SSH/IAP pipes. No plaintext configuration files persist on developer workstations.
  • Workload Identity: Server-to-server Google API requests authenticate dynamically using the VM link-local metadata server (http://metadata.google.internal), minting short-lived OAuth access tokens with 1-hour lifespans.