# GPU cloud team access: API keys and SSH keys have different jobs

Separate cloud API credentials, SSH keys and application tokens for a GPU team, with scoped automation and a tested rotation procedure.

Author: Retrivium team
Updated: 2026-11-01
Canonical URL: https://retrivium.ai/journal/cloud-gpu-account-team-key-rotation/
Language: en

A GPU cloud API key authorizes service operations, while an SSH key normally authenticates access to an operating system. They have different purposes and separate revocation paths. A team needs individually managed access, an inventory of dependent automation and a rotation procedure that has been tested before an urgent change.

## Name each access boundary

Runpod's credentials documentation distinguishes credential types. Avoid calling every secret a server key. A person might lose permission to create cloud resources while retaining SSH access to an existing machine if their public key is still authorized inside the operating system.

| Credential or role | Access it controls |
| --- | --- |
| Cloud role or API key | Resource management operations |
| SSH key | Operating-system authentication |
| Application token | A notebook or model service |
| Storage secret | Reading and writing datasets |

Give each path an owner, purpose and revocation method. One shared secret makes attribution and replacement harder because several unrelated jobs may depend on it.

## Scope automation to its task

Vast.ai documents restricted API keys and revocation. A monitoring script needs different operations from an instance-provisioning service. Identify the smallest required permission set before copying a human administrator's credentials into automation.

Store the secret through the project's intended mechanism. Instructions should describe where an authorized operator obtains it, not contain a working value. Environment variables are a way to pass a secret to a process; they do not guarantee it cannot appear in logs, debugging output or a captured environment. Keep credentials out of images, notebooks and repositories.

## Rehearse a team member's departure

List the person's cloud account access, API keys, SSH authorization on running hosts and interface tokens. Identify any shared jobs that currently rely on their personal credential. Replace those dependencies through managed access before interpreting a broken queue as an infrastructure failure.

Revoke rights through the documented process, update dependent services and test a small allowed operation with the new credential. Separately confirm that the previous path no longer works. Replacing an API key does not prove that SSH access has disappeared from every existing instance.

## Rotate with a concrete sequence

Providers differ in whether old and new credentials can overlap. Vast.ai documents immediate invalidation of the old value after reset, so do not assume there is a grace period. Prepare the update order for CI, local tools, launch services and backups in advance.

Test revocation first with a separate, minimally privileged credential rather than the only administrative route. Record recovery responsibilities and avoid handing a private SSH key to a colleague as an onboarding shortcut; create their own managed access. That makes responsibility for the proposed equipment clear.

Official references: [docs.runpod.io — credentials](https://docs.runpod.io/get-started/credentials), [docs.vast.ai — api keys](https://docs.vast.ai/guides/reference/api-keys).

Related guides: [Runpod SSH keys: prepare credentials and choose a connection](/journal/runpod-ssh-public-key-setup/), [Accessing Jupyter on a cloud GPU through an SSH tunnel](/journal/cloud-gpu-jupyter-ssh-tunnel/).