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

Клиентские библиотеки и Spring Cloud GCP

К сервисам GCP обращаются через клиентские библиотеки Google Cloud для Java, а в Spring-приложениях удобнее через набор стартеров Spring Cloud GCP: он подключает Cloud Storage, Pub/Sub, Secret Manager и другие сервисы в привычном для Spring стиле — через конфигурацию и внедрение зависимостей.

Storage storage = StorageOptions.getDefaultInstance().getService();
storage.create(
    BlobInfo.newBuilder("my-bucket", "report.pdf").build(),
    bytes);

Application Default Credentials: откуда берутся права

Главный принцип — никаких секретов в коде. За получение доступа отвечает Application Default Credentials (ADC) — библиотека перебирает источники учётных данных по очереди и берёт первый доступный:

  • в облаке (Compute Engine, Cloud Run, GKE) — это привязанный сервисный аккаунт: платформа выдаёт временный токен через сервер метаданных, в коде ни ключа, ни пароля;
  • на машине разработчика — учётка из gcloud auth application-default login, под которой вы вошли;
  • в CI вне GCP — Workload Identity Federation вместо вечного JSON-ключа.

Один и тот же код работает и локально, и в облаке — меняется только источник учётных данных. Это избавляет от соблазна захардкодить ключ.

Подключение к Cloud SQL

К Cloud SQL подключаются обычным JDBC-драйвером PostgreSQL, но не по внешнему IP, а через Cloud SQL Java-коннектор (socket factory) или Auth Proxy: он устанавливает защищённое соединение по правам сервисного аккаунта, так что у базы нет публичного адреса и пароль не ходит в открытом виде. Memorystore (Redis) подключают стандартным клиентом по внутреннему адресу.

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

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

  • для Cloud Storage поднимают локальный эмулятор (например, fake-gcs-server) в контейнере через Testcontainers;
  • для Pub/Sub — официальный эмулятор Pub/Sub;
  • для PostgreSQL, Redis используют те же Testcontainers с обычными образами — managed-сервис в тестах не нужен, драйвер один и тот же.

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

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

Эта связка — как приложение аутентифицируется через сервисный аккаунт (ADC) и ходит в облачные сервисы через клиентские библиотеки — стоит за любым боевым сервисом в GCP. ADC делает так, что один код работает в любом окружении, а секреты не оседают в репозитории.

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

  • кладут JSON-ключ сервисного аккаунта в git или код — классическая утечка;
  • жёстко прописывают путь к ключу вместо ADC — код не переносится между окружениями;
  • подключаются к Cloud SQL по внешнему IP вместо коннектора — открывают базу наружу;
  • тестируют против реального облака вместо эмуляторов и Testcontainers — тесты медленные и хрупкие.

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