# Командный доступ к GPU-облаку: API-ключ и SSH-ключ решают разные задачи

Как организовать командный доступ к GPU-облаку: API-ключ для управления ресурсами, SSH-ключ для ОС, ограничение полномочий и порядок отзыва сотрудника.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/cloud-gpu-account-team-key-rotation/
Language: ru

API-ключ GPU-облака управляет запросами к сервису, а SSH-ключ обычно подтверждает вход в операционную систему. Они решают разные задачи и отзываются отдельно. Для команды нужны персонально управляемые права, список зависимых автоматизаций и проверяемая процедура замены ключей.

## Разведите два уровня доступа

[Документация credentials Runpod](https://docs.runpod.io/get-started/credentials) описывает разные виды учётных данных. Не используйте слово «ключ сервера» для всех секретов проекта. Человек может потерять право создавать Pods, но сохранить вход в уже работающую ОС, если соответствующий публичный SSH-ключ остаётся внутри.

| Доступ | Что позволяет проверить |
| --- | --- |
| Облачная роль или API-ключ | Операции управления ресурсами |
| SSH-ключ | Аутентификацию пользователя ОС |
| Токен приложения | Доступ к notebook или сервису |
| Секрет хранилища | Чтение и запись данных |

У каждого пути должен быть владелец, назначение и способ отзыва. Единый общий секрет затрудняет понимание, кто выполнял действие и какие процессы перестанут работать после замены.

## Ограничивайте автоматизацию её задачей

[Руководство API keys Vast.ai](https://docs.vast.ai/guides/reference/api-keys) описывает создание ограниченных ключей и их отзыв. Для скрипта наблюдения нужны одни полномочия, для запуска экземпляров — другие. Не переносите полный доступ человека в автоматизацию без проверки необходимого набора операций.

Секрет храните в предназначенном для проекта механизме, а в инструкции фиксируйте только имя и место получения. Действующие значения не должны попадать в образ, notebook, публичную команду или репозиторий. Переменная окружения удобна для передачи процессу, но не делает секрет безопасным автоматически во всех журналах.

## Пример ухода участника проекта

Сотрудник завершает работу с GPU-пилотом. Администратор сначала составляет перечень: облачная учётная запись, API-ключи, SSH на действующих машинах и токены интерфейсов. Затем определяет зависимые автоматизации, чтобы отзыв персонального доступа не стал необъяснимым сбоем общей очереди.

Права отзывают по документированному процессу, заменяют используемые секреты и проверяют, что рабочие задачи продолжаются через новые учётные данные. Отдельно подтверждают невозможность прежнего входа. Одна успешная замена API-ключа не доказывает удаления SSH-доступа внутри всех экземпляров.

## Планируйте ротацию без догадок

У разных продуктов различаются правила reset и наличие периода совместного действия старого и нового ключа. Например, документация Vast.ai указывает немедленную недействительность старого значения после reset. Поэтому последовательность обновления автоматизаций нужно готовить заранее, а не предполагать окно перекрытия.

Сохраните список мест использования: CI, локальный CLI, сервис запуска и резервное копирование. После ротации проверьте каждое небольшим разрешённым действием. Если секрет оказался раскрыт, обновление только одной копии оставит остальные процессы с неработающим либо скомпрометированным значением.

Для учебной проверки отзыва используйте отдельный тестовый доступ с минимальными правами. Подтвердите разрешённую операцию, отзовите полномочие и убедитесь, что прежний путь больше не действует. Такой опыт позволяет уточнить процедуру команды без эксперимента над единственным административным ключом действующей среды.

## Сделайте доступ передаваемым

В рабочей инструкции должны быть ответственные, минимальные роли и порядок восстановления административного доступа. Приватные ключи не передаются коллеге как способ добавить нового участника; ему создают собственный управляемый путь.

Для деталей прочитайте [SSH-ключи Runpod](/ru/journal/runpod-ssh-public-key-setup/) и [доступ к Jupyter через туннель](/ru/journal/cloud-gpu-jupyter-ssh-tunnel/). Это позволит обсудить оборудование с понятной ответственностью за доступ.