#Признаки неисправности и область применимости
После выпуска нового ключа сервисного аккаунта интеграция с Yandex Cloud начала возвращать 401, 403 или ошибку подписи. Сначала определите разновидность ключа: API-ключ, авторизованный ключ для JWT и статический ключ для S3 — не взаимозаменяемы.
#Почему это происходит
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Ключ другого типаУ механизмов аутентификации разные форматы и способы передачи. | Приложение ожидает AWS Access Key, ему передан API-ключ | Установите требуемый тип ключа в документации интеграции. |
| Часть экземпляров использует старый секретСекрет сохранён в нескольких узлах, версиях функции или переменных окружения. | Иногда запросы успешны, иногда 401 | Найдите и обновите все потребители. |
| Старый ключ отозван до проверкиКлиент не переключился на новую пару реквизитов либо не перечитал конфигурацию. | Ошибка появилась ровно после удаления старого ключа | Проверьте порядок ротации и журнал. |
#Пошаговая диагностика и устранение
- Установите тип используемой аутентификацииОткройте настройки интеграции в вашем приложении и документацию её поставщика. Запишите, требует ли она статический ключ доступа S3, API-ключ, IAM-токен либо подписанный JWT. Не копируйте значения секретов; достаточно безопасного идентификатора ключа и имени сервисного аккаунта.
- Проверьте статус созданного ключаВ консоли откройте нужный каталог → Identity and Access Management → сервисные аккаунты → нужный аккаунт. Найдите список ключей соответствующего типа и сравните идентификатор/дату создания с настройками клиента. Доступность разделов зависит от IAM-прав.
- Сверьте права владельца ключаУбедитесь, что ключ принадлежит тому же сервисному аккаунту, которому назначены права на нужный сервис или бакет. Новый ключ сам по себе не выдаёт права. Роль, назначенная только на ресурс сервисного аккаунта, не даёт ему доступа к Object Storage.
- Найдите все места хранения секретаПроверьте защищённые переменные окружения, Lockbox, настройки контейнера/функции и конфигурации отдельных серверов. Если приложение работает на нескольких узлах, отметьте каждый узел. Не используйте
echoдля вывода всего секрета в общий журнал и не вставляйте его в команду, которая сохраняется в истории оболочки.
- Обновите секрет безопасным способомВыпустите или используйте новый ключ соответствующего типа, сохраните его в менеджере секретов и через штатное редактирование конфигурации укажите новую пару значений. Для S3 обновляются и идентификатор, и секрет. На производстве выполняйте поузловое переключение, проверяя ошибки после каждого узла.
- Перезапустите только нужного потребителяЕсли процесс читает переменные лишь при старте, примените новую версию функции, перезапустите соответствующий контейнер или службу по инструкции вашего развёртывания. Не перезапускайте все ВМ и не меняйте чужие приложения. Проверьте время запуска в журнале.
- Выполните минимальную разрешённую пробуВызовите безопасную операцию чтения статуса или получения одного тестового объекта через само приложение; если ошибка остаётся, запишите HTTP-код и код аутентификации без секрета. Для S3 отдельно различайте SignatureDoesNotMatch и AccessDenied — причины у них могут отличаться.
- Отзовите старый ключ только после переключенияПосле успешного тестирования на всех экземплярах согласуйте удаление старого ключа в IAM, проверьте отсутствие продолжающих использовать его клиентов и зафиксируйте изменение. Если тест не прошёл, верните конфигурацию к предыдущему работавшему ключу, если он ещё активен.
#Как проверить, что проблема исправлена
Пробный запрос проходит через каждую действующую версию интеграции; после планового отзыва старого ключа количество 401/403 не растёт. У сервиса сохранён только необходимый набор прав, реквизиты отсутствуют в журналах.
#Если проблема осталась
Если новый ключ вообще не виден приложению, проверьте, что среда выполнила обновление переменных или версии функции. Если появляются 403 при корректной аутентификации, сверяйте роли аккаунта и политику ресурса, а не перевыпускайте ключи бесконечно.