Ошибка SSL-сервера Cloud SQL Proxy: "в сертификате указан CN "", ожидаемый регион "<project>:<>:<instance>"` при подключении к PostgreSQL 14

Мы столкнулись с проблемой с Облачным SQL-прокси (версии 1 и 2) при подключении к недавно созданному экземпляру PostgreSQL 14 Cloud SQL с помощью развертывания Kubernetes на GKE.

Ошибка, которую мы видим в логах, выглядит следующим образом:

certificate had CN "", expected "<project-id>:<region>:<instance-name>"

Контекст:

  • Мы используем Контейнер sidecar Cloud SQL Auth Proxy для проверки подлинности в нашем развертывании GKE.
  • Учетные данные JSON для учетной записи службы с ролью Cloud SQL Client правильно подключены и используются с помощью -credential_file.
  • Строка подключения экземпляра отформатирована правильно.
  • Мы проверили точность секретных подключений и путей.
  • Та же настройка отлично работает для более старого экземпляра PostgreSQL 11.

Наблюдения:

  • Прокси запускается и прослушивает 127.0.0.1:5432, но сразу же завершается сбоем при проверке SSL.
  • Ошибка, по-видимому, связана с тем, что общее имя сертификата (CN) является пустым или недействительным.
  • Имя пользователя , используемое для подключения, отличается от старого экземпляра (proxyuser) по сравнению с новым (postgres), но неясно, связано ли это .

Что мы пробовали:

  • Восстановление и смена ключей учетной записи службы
  • Проверка прав доступа к IAM
  • Проверка правильности установки секретных данных
  • Запуск прокси-сервера локально с теми же учетными данными (та же ошибка)

Вопрос:

Что могло привести к тому, что прокси-сервер Cloud SQL Auth отклонил соединение из-за несоответствия сертификата CN ""?
Есть ли неправильная настройка на уровне SSL или что-то специфичное для экземпляров PostgreSQL 14?

Мы были бы признательны за рекомендации по безопасному разрешению этой проблемы без раскрытия внутренних данных проекта. Заранее спасибо!

Похоже, что Cloud SQL Auth Proxy не удалось настроить прокси-соединения с экземпляром. Вероятно, это связано с тем, что версия language connectors/auth proxy слишком старая. Вы пробовали обновить свою версию Cloud SQL proxy? Если вы используете Cloud SQL Auth Proxy, убедитесь, что вы используете самую последнюю версию, см. раздел поддержание прокси-сервера Cloud SQL Auth в актуальном состоянии.

Вы также можете ознакомиться с этой документацией о Требованиях к использованию прокси-сервера Cloud SQL Auth, в ней упоминаются подключения к экземплярам Cloud SQL с использованием (общего/ управляемого клиентом) центра сертификации (CA) с рекомендуемыми Версия прокси-сервера для проверки подлинности облачного SQL.

Если обновление версии прокси-сервера у вас не работает и если у вас есть пакет поддержки, я бы порекомендовал вам обратиться за помощью к Службе поддержки Google Cloud для более подробного анализа ваша проблема.

У меня аналогичная проблема с сообщением об ошибке: не удалось установить облачное SQL-соединение. Пожалуйста, смотрите https://cloud.google.com/sql/docs/mysql/connect-run для получения дополнительной информации: в сертификате указан CN "", ожидается "<project_id>:<instance_id>"

У меня есть простая настройка, в которой я развертываю свой серверный API Ruby в облачной службе запуска с использованием артефакта и подключаю его к базе данных PostgreSQL на Cloud SQL. Я пытаюсь подключить оба устройства через сокет UNIX, поскольку это кажется правильным способом сделать это (а не по протоколу TCP).

В моей конфигурации запуска в облаке я специально выбрал экземпляр базы данных, чтобы автоматически устанавливать сокет в фоновом режиме (согласно документации Google Cloud). Согласно документации, я не должен настраивать прокси-сервер облачной аутентификации с помощью этой настройки, однако я не могу заставить его работать, соединение всегда прерывается.

Вернуться на верх