Network and Service Integration#
To the rest of the infrastructure, the CVM looks like an HTTPS inference service. HTTPS is the reference path. Other TLS-protected application protocols, such as gRPC over TLS or WebSockets over TLS (wss://), can fit the same boundary when authentication, routing, logging, and payload-handling controls are equivalent.
The service sits behind whatever gateway, inference router, model registry endpoint, or load balancer the platform already uses.
The default pattern is simple: inbound HTTPS from approved callers, outbound HTTPS to attestation, key release, artifact storage, and approved application endpoints. No SSH. Administrative access happens by replacing the image, through platform automation, or through a governed break-glass that doesn’t expose model-provider secrets.
Firewall policy permits:
Inbound inference traffic from the approved gateway or service subnet.
Outbound HTTPS/443 from the CVM to the attestation verifier.
Outbound HTTPS/443 from the CVM to the key broker or KMS/HSM.
Optional outbound traffic to an approved registry or object store for artifact fetches.
Optional outbound traffic for model-provider licensing or telemetry, if contractually allowed.
Broad outbound internet access is denied. Anything that calls home does so as documented application traffic, not via hardware or BMC paths.
Service discovery can be static for validation and early production — fixed IPs, a DNS record, or a small load-balanced pool. Larger deployments add automation for VM launch, certificate issuance, health registration, and replacement.
The surrounding platform treats the CVM as an HTTPS inference endpoint. Cluster administrators don’t enter the guest, install agents, tail application logs with payloads, or run commands inside the model server.