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

Azure SDK и Spring Cloud Azure

К сервисам Azure обращаются через Azure SDK for Java, а в Spring-приложениях удобнее через набор стартеров Spring Cloud Azure: он подключает Blob Storage, Service Bus, Key Vault и другие сервисы в привычном для Spring стиле — через конфигурацию и внедрение зависимостей.

BlobServiceClient blob = new BlobServiceClientBuilder()
    .endpoint("https://mystorage.blob.core.windows.net")
    .credential(new DefaultAzureCredentialBuilder().build())
    .buildClient();

Управляемые PostgreSQL и Redis вообще не требуют «облачного» SDK: к ним подключаются стандартными драйверами (JDBC для PostgreSQL, Lettuce/Jedis для Redis) по адресу и с паролем managed-кластера — как к любой базе.

DefaultAzureCredential: откуда берутся права

Главный принцип — никаких секретов в коде. За получение доступа отвечает DefaultAzureCredential — она перебирает источники учётных данных по очереди и берёт первый доступный:

  • в облаке (виртуальная машина, Container Apps, AKS) — это managed identity: платформа выдаёт временный токен, в коде ни пароля, ни ключа;
  • на машине разработчика — учётка из Azure CLI, под которой вы вошли (az login);
  • в CI вне Azure — service principal, чей секрет хранят в защищённом хранилище конвейера, а не в git.

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

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

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

  • для Blob Storage и очередей поднимают Azurite — официальный локальный эмулятор хранилища — в контейнере через Testcontainers; клиент переключается на него сменой endpoint;
  • для PostgreSQL, Redis используют те же Testcontainers с обычными образами — managed-сервис в тестах не нужен, драйвер один и тот же.

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

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

Эта связка — как приложение аутентифицируется через managed identity и ходит в облачные сервисы через SDK — стоит за любым боевым сервисом в Azure. DefaultAzureCredential делает так, что один код работает в любом окружении, а секреты не оседают в репозитории.

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

  • кладут строку подключения с ключом в git или в код — классическая утечка;
  • жёстко прописывают учётные данные вместо DefaultAzureCredential — код не переносится между окружениями;
  • тестируют против реального облака вместо Azurite и Testcontainers — тесты медленные и хрупкие;
  • дублируют доступ через ключи там, где хватило бы managed identity.

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