В этом материале
Отзыв доступа требует отдельной проверки облачных полномочий и входа в ОС; замена одного ключа не закрывает все пути.
API-ключ GPU-облака управляет запросами к сервису, а SSH-ключ обычно подтверждает вход в операционную систему. Они решают разные задачи и отзываются отдельно. Для команды нужны персонально управляемые права, список зависимых автоматизаций и проверяемая процедура замены ключей.
Разведите два уровня доступа
Документация credentials Runpod описывает разные виды учётных данных. Не используйте слово «ключ сервера» для всех секретов проекта. Человек может потерять право создавать Pods, но сохранить вход в уже работающую ОС, если соответствующий публичный SSH-ключ остаётся внутри.
| Доступ | Что позволяет проверить |
|---|---|
| Облачная роль или API-ключ | Операции управления ресурсами |
| SSH-ключ | Аутентификацию пользователя ОС |
| Токен приложения | Доступ к notebook или сервису |
| Секрет хранилища | Чтение и запись данных |
У каждого пути должен быть владелец, назначение и способ отзыва. Единый общий секрет затрудняет понимание, кто выполнял действие и какие процессы перестанут работать после замены.
Ограничивайте автоматизацию её задачей
Руководство API keys Vast.ai описывает создание ограниченных ключей и их отзыв. Для скрипта наблюдения нужны одни полномочия, для запуска экземпляров — другие. Не переносите полный доступ человека в автоматизацию без проверки необходимого набора операций.
Секрет храните в предназначенном для проекта механизме, а в инструкции фиксируйте только имя и место получения. Действующие значения не должны попадать в образ, notebook, публичную команду или репозиторий. Переменная окружения удобна для передачи процессу, но не делает секрет безопасным автоматически во всех журналах.
Пример ухода участника проекта
Сотрудник завершает работу с GPU-пилотом. Администратор сначала составляет перечень: облачная учётная запись, API-ключи, SSH на действующих машинах и токены интерфейсов. Затем определяет зависимые автоматизации, чтобы отзыв персонального доступа не стал необъяснимым сбоем общей очереди.
Права отзывают по документированному процессу, заменяют используемые секреты и проверяют, что рабочие задачи продолжаются через новые учётные данные. Отдельно подтверждают невозможность прежнего входа. Одна успешная замена API-ключа не доказывает удаления SSH-доступа внутри всех экземпляров.
Планируйте ротацию без догадок
У разных продуктов различаются правила reset и наличие периода совместного действия старого и нового ключа. Например, документация Vast.ai указывает немедленную недействительность старого значения после reset. Поэтому последовательность обновления автоматизаций нужно готовить заранее, а не предполагать окно перекрытия.
Сохраните список мест использования: CI, локальный CLI, сервис запуска и резервное копирование. После ротации проверьте каждое небольшим разрешённым действием. Если секрет оказался раскрыт, обновление только одной копии оставит остальные процессы с неработающим либо скомпрометированным значением.
Для учебной проверки отзыва используйте отдельный тестовый доступ с минимальными правами. Подтвердите разрешённую операцию, отзовите полномочие и убедитесь, что прежний путь больше не действует. Такой опыт позволяет уточнить процедуру команды без эксперимента над единственным административным ключом действующей среды.
Сделайте доступ передаваемым
В рабочей инструкции должны быть ответственные, минимальные роли и порядок восстановления административного доступа. Приватные ключи не передаются коллеге как способ добавить нового участника; ему создают собственный управляемый путь.
Для деталей прочитайте SSH-ключи Runpod и доступ к Jupyter через туннель. Это позволит обсудить оборудование с понятной ответственностью за доступ.