ЦС SSL-сервера Google Cloud повернуть
Консоль Google Cloud сообщает нам о приближающемся истечении срока действия сертификата в экземпляре Google Cloud SQL.
У нас есть несколько сервисов, которые подключаются к этому экземпляру базы данных:
- Compute Engine (через прокси-сервер Cloud SQL -
cloud_sql_proxy_x64) - AppEngine
- Рабочий стол (через Cloud SQL Proxy -
cloud_sql_proxy_x64)
Вопросы
Когда мы меняем сертификат, нужно ли будет перезагружать все, чтобы получить новое соединение? Или службы будут просто использовать новый сертификат при необходимости?
Потеряют ли экземпляры Compute Engine подключение к серверу SQL?
Мне нужно будет удалить экземпляры AppEngine, чтобы заставить их повторно подключиться, или они просто продолжат работу?
Мы стараемся предотвратить простои во время этой работы. Ваше понимание ценится.
Вот что отображается на панели управления Cloud SQL: 
Короткий ответ: в ваших текущих развертываниях с использованием прокси-сервера Cloud SQL и управляемых сервисов в App Engine вы сможете внести это изменение. без простоев.
Я рекомендую ознакомиться с документацией Cloud SQL на ротация сертификатов (этот документ относится к MySQL; есть аналогичный документ для PostgreSQL). Из документов есть пара замечаний:
Явная конфигурация SSL / TLS только требуется, когда вы подключаетесь к экземпляру напрямую, используя его IP-адрес:
SSL / TLS необходим для обеспечения безопасности при подключении к Cloud SQL с использованием IP-адресов.
Если вы используете компонент Cloud SQL Proxy, он будет иметь дело с инкапсуляцией и защитой соединения с экземпляром базы данных от вашего имени. Это включает в себя другое главное преимущество Cloud SQL Proxy: нет необходимости явно заносить в белый список IP-адреса подключаемых хостов, что может быть невозможно в облачной среде, где хосты недолговечны с эфемерными IP-адресами.
Cloud SQL использует самозаверяющие сертификаты TLS:
Cloud SQL использует самозаверяющий сертификат сервера для каждого экземпляра
Это важно для любых приложений, которые подключаются напрямую с помощью IP-адреса. Чтобы гарантировать, что они обмениваются данными с законным хостом Cloud SQL, такие приложения должны быть настроены для проверки сертификата сервера при первоначальном подключении. Поскольку сертификат является самоподписанным, они могут сделать это только в том случае, если у них есть локальная копия сертификата для сравнения.
Это причина многоступенчатого процесса обновления. Вам предоставляется возможность загрузить новый сертификат и настроить свои приложения для приема как старого, так и нового сертификата, прежде чем сделать его активным на вашем хосте.
Файл, загруженный с новым сертификатом сервера, содержит как текущий, так и будущий (новый) сертификат, поэтому он совместим для подключений к экземпляру, независимо от того, какая версия сертификата является «текущей» на сервере в точке подключения. Наиболее важным требованием является то, что вы не делаете «предстоящий» сертификат «текущим» до тех пор, пока все нижестоящие клиенты, подключающиеся через IP, не получат новый файл сертификата, поскольку они не смогут проверить подлинность сервера.