Разобраться, какие в облаке есть сервисы, — половина дела. Вторая половина — обратиться к ним из кода так, чтобы это было безопасно (без секретов в репозитории) и тестируемо (без реального облака в тестах). Разберём это на примере Spring Boot. Прежде чем читать, полезно понимать модель доступа из статьи про Cloud IAM — весь фокус тут в том, откуда приложение берёт права.

Object Storage через AWS SDK

Поскольку Object Storage совместим с Amazon S3, обращаются к нему обычным AWS SDK for Java (v2) — тем же, что и к настоящему S3. Отличие одно: указать адрес хранилища Yandex Cloud.

S3Client s3 = S3Client.builder()
    .endpointOverride(URI.create("https://storage.yandexcloud.net"))
    .region(Region.of("ru-central1"))
    .credentialsProvider(credentialsProvider)
    .build();

Дальше — привычные putObject, getObject, presigned URL: код не отличается от работы с AWS S3. Это большой плюс: экосистема S3 (библиотеки, инструменты, знания) переносится как есть.

Message Queue через SQS-совместимый клиент

Аналогично Message Queue совместим с Amazon SQS — значит, работают SQS-клиенты AWS SDK, нужно лишь задать endpoint очереди Yandex Cloud. Управляемые PostgreSQL, Redis и Kafka вообще не требуют «облачного» SDK: к ним подключаются стандартными драйверами (JDBC для PostgreSQL, Lettuce/Jedis для Redis, обычный клиент Kafka) по адресу и с паролем управляемого кластера — как к любой базе.

Аутентификация: откуда берутся права

Главный принцип — никаких секретов в коде. Как приложение получает доступ, зависит от того, где оно работает:

  • На виртуальной машине или в Managed Kubernetes к нагрузке привязывают сервисный аккаунт, и приложение получает временный IAM-токен из сервиса метаданных автоматически. В коде — ни пароля, ни ключа.
  • Для Object Storage часто используют статический ключ доступа (пара «идентификатор + секрет» в стиле S3). Его держат не в репозитории, а в Lockbox или в переменных окружения, которые подставляет платформа деплоя.
  • Извне облака (например, из CI) — через авторизованный ключ сервисного аккаунта, который тоже хранят в защищённом хранилище секретов, а не в git.

Правило: внутри облака — привязанный сервисный аккаунт и метаданные; ключ-файл или статический ключ — только там, где иначе никак, и всегда из защищённого хранилища.

Тестирование без облака

Гонять тесты против реального облака — медленно, дорого и требует доступа. Поэтому его подменяют локально:

  • для Object Storage поднимают локальный S3-совместимый сервер (например, MinIO) в контейнере через Testcontainers — код с endpointOverride переключается на него одной строкой конфигурации;
  • для PostgreSQL, Redis, Kafka используют те же Testcontainers с обычными образами — управляемый сервис в тестах не нужен, драйвер один и тот же.

Так интеграционные тесты идут быстро и не зависят от сети и облака. Общие подходы к тестированию — в разделе тестирования.

Где это применяется

Эта связка — как приложение аутентифицируется через сервисный аккаунт и ходит в облачные сервисы через знакомые SDK — стоит за любым боевым сервисом в Yandex Cloud. Совместимость с S3 и SQS означает, что большая часть кода не «привязана к Яндексу» и переносима.

Типичные ошибки новичков:

  • кладут статический ключ Object Storage в git или в код — классическая утечка;
  • забывают про endpointOverride и стучатся в настоящий AWS вместо Yandex Cloud;
  • тестируют против реального облака вместо локальной подмены — тесты медленные и хрупкие;
  • дублируют доступ через ключи там, где хватило бы привязанного сервисного аккаунта.

Что учить дальше: где хранить секреты и как читать логи и метрики приложения — в безопасности и наблюдаемости; сами сервисы данных — в управляемых данных и Object Storage. Аналогичный разбор для AWS — AWS из Spring Boot.