Последние две пятницы без какого-либо уведомления в Google Cloud заблокировали доступ к аккаунту моей компании SSLMate. Впервые подобное произошло в 2024 году, тоже без какого-либо предупреждения. Но сегодня я хочу не столько предупредить вас о рисках использования платформы Google Cloud, сколько поведать о вынужденных компромиссах между снижением безопасности и удобством работы, вызванных своенравной политикой Google.

Помимо тестирования и экспериментов, единственная причина, по которой я размещаю SSLMate на Google Cloud — это интеграция сервиса с облачными аккаунтами наших клиентов, которая позволяет нам публиковать DNS-записи для проверки сертификатов и определять домены, которые нужно мониторить от их имени.

Для каждого клиента мы создаём сервисный аккаунт в нашем проекте Google Cloud и просим его дать этому аккаунту доступ к Cloud DNS и Cloud Domains. Впоследствии, когда SSLMate требуется получить доступ к учётной записи клиента Google Cloud, сервис использует для этого соответствующий сервисный аккаунт. Я разработал эту систему на основе идеи, описанной в документации самой компании Google (в разделе «How can I access data from my users' Google Cloud project using Cloud APIs?»), и работает она прекрасно. К тому же, этот метод отличается простотой настройки и высоким уровнем безопасности, так как учётные данные не хранятся долгое время, и не возникает уязвимость типа «Confused Deputy».

Простота и безопасность — радует, когда такое возможно!

Единственная проблема в том, что Google периодически блокирует нам доступ к Google Cloud.

Первая блокировка

Впервые доступ был приостановлен в 2024 году. Тогда начали происходить сбои в работе интеграций наших клиентов, и при авторизации в консоли Google Cloud возникала такая ошибка:

Должен сказать, что поддержка Google сработала на удивление отзывчиво, хотя в таких вопросах это на них совсем не похоже. Тем не менее сам процесс восстановления аккаунта оказался весьма проблемным:

• Сначала они потребовали прислать им письмо с адреса, привязанного к моей учётной записи. Но отправленное письмо вернулось с ошибкой: «The account [redacted] is disabled» (под redacted был указан адрес, с которого я отправлял письмо). Тогда я отправил сообщение с другого адреса, и оно прошло, но поначалу специалисты поддержки отказывались на него реагировать, так как оно было отправлено не с того адреса.

• Позже они попросили меня предоставить ID наших проектов Google Cloud — информацию, которую я не мог получить, так как не мог авторизоваться в консоли. А вы сохраняете ID вашего проекта в безопасном месте на случай блокировки аккаунта?

• Обменявшись с поддержкой несколькими сообщениями и подтвердив свой номер телефона, я смог авторизоваться в консоли платформы, но два из наших проектов по-прежнему были заблокированы, включая необходимый для работы клиентских интеграций. (В то время часть наших доменов ещё была зарегистрирована через сервис Google Clouds Domains, доступ к которому, к счастью, был сохранён. Это позволило мне начать переводить домены под крыло более надёжного регистратора).

• На следующий день после восстановления доступа к консоли с адреса no-reply@accounts.google.com пришло автоматическое письмо, в котором говорилось, что мой доступ к Google Cloud Platform был ограничен. Я снова потерял доступ к консоли, но на сей раз сообщение было другое:

• Через двенадцать часов я получил несколько автоматических писем от google-cloud-compliance@google.com, в которых говорилось, что мои проекты на Google Cloud были «восстановлены», но войти в консоль я по-прежнему не мог.

• Ещё через семь часов поступило очередное автоматическое письмо с no-reply@accounts.google.com. В нём сообщалось, что мой доступ к Google Cloud восстановлен. Вот тогда всё заработало.

Мне так никто и не объяснил, почему мой аккаунт был заблокирован, и как этого избежать в будущем. Несмотря на обещания Google оповещать о блокировке аккаунта или проекта, такого уведомления на момент изначальной блокировки не поступало. Поскольку ошибки в работе клиентских интеграций отображались только в консолях клиентов SSLMate (обычно ошибка указывает на то, что клиент допустил оплошность), узнал я о сбое не сразу. Чтобы избежать такого в будущем, я добавил проверку работоспособности системы, которая проваливается, если ошибки возникают во множестве интеграций Google Cloud.

Вторая блокировка

И в позапрошлую пятницу эта проверка провалилась. Я сразу же полез разбираться и увидел, что все интеграции Google Cloud, кроме одной падали с той же ошибкой, которая возникала во время прошлогодней блокировки («Invalid grant: account not found»). С чувством глубокой досады я попытался авторизоваться в консоли Google Cloud, предчувствуя очередной кафкианский процесс восстановления доступа. «Ну на сей раз я хотя бы знаю ID проектов», — успокаивал я себя.

К моему удивлению, авторизация прошла успешно. Потом на почту прилетели письма — по одному для каждого проекта Google Cloud. В них говорилось, что мои проекты были восстановлены «на основе предоставленной [мной] информации». Естественно, никаких писем об их изначальной приостановке я не получал. Интеграции заработали.

Третья блокировка

В прошлую пятницу проверка работоспособности системы снова провалилась. Тогда я попробовал авторизоваться в консоли Google Cloud, уже не зная, чего и ожидать. На этот раз сообщение об ошибке снова было другое:

Приостановлены оказались большинство проектов SSLMate, включая необходимый для обработки клиентских интеграций.

В ту же пятницу я отправил запрос на обжалование. Ответ поступил в воскресенье. Думаете, это был ответ на обжалование? Как бы не так! Это было автоматическое письмо, сообщавшее, что доступ SSLMate к Google Cloud полностью заблокирован.

Добавлено после публикации: в понедельник, вскоре после того, как эта статья попала на главную страницу Hacker News, работа большинства проектов была восстановлена, включая обработку клиентских интеграций. Ещё через несколько часов доступ был восстановлен полностью. Как и прежде, никакого объяснения причин блокировки или способов её избежания в будущем я не получил.

Везучий клиент

Невероятно, но у нас есть один везучий клиент, чья интеграция продолжала работать при каждой блокировке, хотя в ней используется сервисный аккаунт из того же приостановленного проекта, в котором зарегистрированы аккаунты всех других интеграций.

Что теперь?

Ясное дело, что положиться на аккаунт Google в рабочих задачах я не могу. Создатели Google выстроили сложную, ненадёжную систему, в которой неожиданно могут заблокировать что угодно и всё сразу: аккаунт Google целиком, аккаунт Google Cloud Platform или отдельные проекты Google Cloud.

К сожалению, альтернативные решения для реализации интеграций не радуют.

Первый вариант — это попросить клиентов создать сервисный аккаунт для SSLMate и обеспечить аутентификацию в нём SSLMate через долгосрочный ключ. Это совсем несложно, но уже менее безопасно, так как долгосрочный ключ может попасть в чужие руки, а менять его периодически не получится.

Вторая альтернатива — это использование OpenID Connect (OIDC). За последние годы OIDC де-факто стал стандартом для реализации интеграций между разными сервисами. Например, с его помощью вы можете открыть для GitHub Actions доступ к вашему аккаунту Google Cloud без использования долгосрочных учётных данных. Интеграция SSLMate с Azure реализована как раз через OIDC и работает прекрасно.

Но, к сожалению, в Google излишне усложнили настройку OIDC. Тот простой механизм из одного шага, которым сейчас наши клиенты могут добавить интеграцию (присвоение определённых ролей сервисному аккаунту) в случае OIDC станет сложным процессом из семи этапов. Потребуется:

1. Включить IAM Service Account Credentials API.

2. Создать сервисный аккаунт.

3. Создать пул идентификаторов рабочих нагрузок (Workload Identity Pool).

4. Создать провайдера идентификаторов рабочих нагрузок в этом пуле.

5. Позволить SSLMate выполнять действия от имени сервисного аккаунта, созданного на этапе 2 (для этого потребуется знать ID пула из этапа 3).

6. Присвоить роли сервисному аккаунту из этапа 2.

7. Предоставить SSLMate ID этого аккаунта и ID провайдера, созданного на этапе 4.

Поскольку многие из этих шагов требуют знания идентификаторов ресурсов, созданных на предыдущих шагах, сложно дать клиентам SSLMate простые и понятные инструкции.

Процесс получается неоправданно усложнённый, хотя:

• Создание сервисного аккаунта (шаги 1, 2 и 5) не должно быть обязательным. Несмотря на то, что можно воздержаться от этого и присваивать роли напрямую идентификатору из пула, это возможно не для всех сервисов Google Cloud. Если вы хотите, чтобы ваша интеграция работала со всеми текущими и будущими сервисами, то без сервисного аккаунта не обойтись. Google следует перестать относиться к OIDC как к побочной платформе и обеспечить её прямую поддержку всеми имеющимися и будущими сервисами.

• Создание пула идентификаторов тоже не должно быть обязательным. Безусловно, они хорошо подходят для некоторых случаев, но в большинстве конфигураций наверняка будет не более одного провайдера на пул. В итоге дополнительный этап по созданию этого пула только добавляет ненужной работы.

• Даже создание провайдера не должно быть необходимым. Нужна возможность напрямую присваивать роли на основе URL-адреса эмитента OIDC и конкретного субъекта. Создание провайдера нужно только, когда требуется осуществить более продвинутую настройку, например, сопоставить атрибуты.

Считаю, что нынешнее положение вещей неприемлемо, так как очень важно исключить использование долгосрочных учётных данных, и в Google должны стремиться к реализации более безопасных альтернатив. Печально, но текущее решение для SSLMate на основе создания провайдером сервисных аккаунтов может сталкиваться с произвольными блокировками учётных записей, а использование OIDC усложняется неоправданно запутанным процессом конфигурации.

В результате при настройке взаимного доступа между провайдерами разных сервисов через Google Cloud вы можете обеспечить лишь два пункта из следующих:

• Отсутствие опасных долгосрочных учётных данных.

• Простота настройки со стороны клиента.

• Отсутствие внезапных блокировок аккаунтов.