GPU Cloud Security Guide

A GPU workload combines remote shell access, valuable credentials, downloaded software and potentially sensitive model inputs. Secure the path from workstation to instance to artifact storage, with explicit ownership for each control. Renting compute does not automatically secure the notebook or model server you install.

Separate account, API and SSH credentials

Use individual account access and protect recovery channels. Platform API keys should have only the scopes the application needs; model discovery and generation use different scopes. Active account status, email verification, key expiry/revocation and configured IP restrictions are enforced by the API. Review API-key controls; never ship a bearer key in browser JavaScript or a public notebook.

Generate SSH keys locally, protect the private key with a passphrase and restrictive file permissions, and register only the public key. Connect with the exact assigned host, username and port after readiness. Verify the displayed host fingerprint before trusting a new destination. An unexpected change needs investigation rather than StrictHostKeyChecking=no. Follow SSH verification.

Keep development services private

Bind notebooks and experimental model servers to loopback and use SSH forwarding when appropriate. A localhost bind inside a container is not identical to a host bind, and publishing Docker ports can expose a service unexpectedly. Verify the effective listener and reachability rather than assuming a framework's default is private.

A deliberately public service needs authentication, TLS, request-size limits, concurrency control and safe output handling at a boundary you manage. CORS is not authentication. Do not expose a Docker daemon or mount its socket into an untrusted notebook to make deployment easier: daemon control can confer extensive host access.

Review images, models and privileges

Pin reviewed image digests and model revisions. Install through official project channels, inspect required extensions and remote-code loading, and keep a known-good image for recovery. An apparently harmless model loader can execute repository code when you explicitly enable that behavior. Avoid providing production secrets during initial artifact inspection.

Run application processes without unnecessary privileges, restrict mounts to required directories and use read-only mounts where possible. Avoid privileged containers and host-wide mounts unless a reviewed workload genuinely requires them. Docker's security documentation explains daemon access, namespaces, capabilities and why configuration matters; containers are not a substitute for all host security controls.

Control data and diagnostic retention

Map where prompts, outputs, checkpoints, caches and logs are written. Keep only data needed for the task and verify permissions on export destinations. Log request IDs, timestamps and safe error categories instead of keys or complete prompts. Model-generated text is untrusted input to any downstream tool, renderer or command executor.

Check the applicable privacy policy, data-processing terms and chosen offering's documented storage behavior before sensitive work. This operational guide does not establish a compliance certification, data-residency guarantee or a verified deletion mechanism for an unspecified disk.

Prepare an incident and termination procedure

If a secret leaks, revoke or rotate the affected credential through its owning system, contain exposed services and preserve redacted evidence. Rebuild from a known-good image when integrity is uncertain instead of treating a package reinstall as proof of recovery. Contact support with safe identifiers and UTC times.

Before termination, export required artifacts and verify recovery access. Remove temporary access and review remaining credentials afterward. Confirm platform termination status; closing SSH is not cleanup. Do not infer certified media erasure from instance termination without an explicit documented commitment.