Два вопроса возникают у любого сервиса, как только он выходит за пределы «работает на моём ноутбуке»: где хранить секреты (пароли к базе, ключи, токены) и как понять, что происходит внутри, когда что-то идёт не так. Первое — про безопасность, второе — про наблюдаемость. В GCP под каждую задачу есть сервис. Доступ ко всем ним выдаётся через Cloud IAM.
Secret Manager
Secret Manager — управляемое хранилище секретов: паролей, ключей, токенов. Идея простая: секреты не живут в коде, в конфигах и в git, а лежат в Secret Manager, откуда приложение забирает их по правам своего сервисного аккаунта.
Зачем так, а не «положить пароль в переменную окружения и забыть»:
- секрет в одном месте, а не размазан по десяти конфигам и репозиториям;
- доступ к нему — по правам IAM, и видно, кто его читал;
- секреты версионируются: можно обновить (ротация) и откатиться, не переклеивая по всем сервисам вручную.
Правило новичку: любой пароль или ключ, попавший в git, считается скомпрометированным. Даже если удалить его следующим коммитом — он останется в истории. Secret Manager снимает соблазн «просто захардкодить».
Cloud KMS
Cloud KMS (Key Management Service) управляет ключами шифрования. Он нужен, когда данные надо шифровать, но сами ключи не хочется хранить рядом с данными. KMS хранит ключи, а сервисы обращаются к нему, чтобы зашифровать и расшифровать; на ключах KMS шифруют диски, бакеты, базы. Для новичка достаточно понимать: данные шифруются, а доступ к ключам — отдельно управляемое право.
Cloud Logging и Cloud Monitoring
Эти сервисы (исторически известные как Stackdriver, теперь Cloud Operations) закрывают наблюдаемость.
Cloud Logging собирает логи со всех ресурсов в одно место, где их можно искать и фильтровать; приложения и managed-сервисы пишут туда автоматически. Практический совет: пишите логи структурированно (с полями — уровень, идентификатор запроса, сервис), а не сплошным текстом — по структурированным логам можно искать и строить фильтры.
Cloud Monitoring показывает картину во времени — метрики (загрузку процессора, задержку, число ошибок), из которых собирают дашборды и алерты — правила вида «если ошибок больше стольки-то за минуту — разбудить дежурного». А Cloud Trace показывает, как запрос проходит сквозь сервисы, и где именно тормозит.
Ключевая мысль для новичка: наблюдаемость нужна до аварии, а не после. Метрики и алерты, настроенные заранее, превращают «пользователи жалуются, а мы не понимаем почему» в «нам пришло уведомление, и мы уже чиним». Общие правила логирования не зависят от облака — их разбирает Observability style guide.
Audit Logs и Security Command Center
Cloud Audit Logs пишет журнал действий над инфраструктурой: кто создал ресурс, кто поменял права, кто удалил базу — незаменимо при разборе инцидентов («откуда взялся этот публичный бакет?»). Security Command Center оценивает состояние безопасности: находит открытые наружу ресурсы, слабые настройки, уязвимости и подсказывает, что исправить.
Где это применяется
Эта связка — секреты в Secret Manager, шифрование на KMS, логи в Cloud Logging, метрики и алерты в Cloud Monitoring — базовый гигиенический минимум любого боевого сервиса. Без неё сервис вроде бы работает, но при первой же проблеме вы оказываетесь слепы.
Типичные ошибки новичков:
- хранят пароли в коде или конфигах вместо Secret Manager;
- логируют бессистемно — сплошным текстом, без идентификатора запроса, и потом ничего не находят;
- настраивают наблюдаемость после первой аварии, а не до неё;
- логируют секреты и персональные данные — и утечка переезжает в логи.
Что учить дальше: как приложение получает доступ ко всему этому без ключей — в Cloud IAM; как обращаться к секретам из кода — в интеграции со Spring Boot; общие правила — в style guide по безопасности и наблюдаемости. Аналогичный набор в AWS — безопасность и наблюдаемость в AWS.