GKE частный кластер и облачный SQL прокси-соединение

Question

У меня есть 2 кластера GKE, как частный, так и общедоступный, и я использую cloudproxy в качестве контейнера-коляски для приложения gke для доступа к экземпляру cloudsql.

настройка общего кластера для разработки / тестирования

Облачный SQL включен как с частным, так и с публичным IP. Приложение GKE использует cloudproxy с опцией по умолчанию для типов ip (public, private), как показано ниже Облачный SQL не имеет авторизованной сети.

В этом случае мое приложение может подключаться к CloudSQL и работает без сбоев. Насколько я понимаю, здесь подключение к cloudsql должно происходить с частным, потому что не настроена авторизованная сеть.

настройка частного кластера для производства

Облачный SQL включен как с частным, так и с публичным IP. Приложение GKE использует cloudproxy с опцией по умолчанию для типов ip (public, private)

параметр облачного прокси-сервера в файле развертывания

  - name: cloudsql-proxy
    image: gcr.io/cloudsql-docker/gce-proxy:1.11
    command: ["/cloud_sql_proxy"]
    args: ["-instances=$(REAL_DB_HOST)=tcp:$(REAL_DB_PORT)","-credential_file=/secrets/cloudsql/credentials.json"]

, кейс 1 Облачный SQL не имеет авторизованной сети. Результат: приложение не может подключиться к Cloud SQL

дело 2 Облачный SQL имеет собственный GKE NAT-шлюз в качестве авторизованной сети. Результат: приложение не может подключиться к Cloud SQL

Может быть, удаление cloudproxy из приложения будет работать (я пока не тестировал), но это препятствует использованию прокси во время dev env, так как это потребует изменений в файле развертывания во время рабочего развертывания.

Я не могу понять, что является причиной сбоя соединения с cloudproxy в частном кластере gke. Разве мы не должны использовать cloudproxy в частном кластере?

Обновление Причина, по которой облачный прокси не смог подключиться к облаку SQL, была отключена Cloud SQL Admin API. Я обновил свой ответ в разделе ответов.

Answer 1

@ kurtisvg предоставил информативный ответ на него.

Однако реальная проблема заключалась в API администратора SQL, и его включение устранило проблему. После просмотра логов я нашел запись ниже.

Ошибка 403: доступ не настроен. API администрирования Cloud SQL ранее не использовался в проекте XXXXXX или он отключен. Включите его, посетив https://console.developers.google.com/apis/api/sqladmin.googleapis.com/overview?

Answer 2

Похоже, здесь вопрос звучит так: «Должны ли мы использовать прокси-сервер Cloud SQL в частном кластере?» и этот ответ "это зависит". Не требуется подключение, но это обеспечивает большую безопасность, поскольку вы можете ограничить ненужный доступ к вашему облачному SQL-серверу.

Облачный прокси-сервер SQL не обеспечивает подключение для вашего приложения - он только обеспечивает аутентификацию. Он должен иметь возможность подключаться по существующему пути, но затем использует роли IAM учетной записи службы для проверки подлинности подключения. Это также означает, что он не должен поступать из сети из белого списка, поскольку он был аутентифицирован с помощью других средств.

Если вы хотите использовать прокси-сервер для подключения через частный IP-адрес (вместо значения по умолчанию для общедоступного), используйте -ip_address_types=PRIVATE - это скажет прокси-серверу подключиться к частному IP-адресу экземпляра. (Обратите внимание, что если прокси-серверу не хватает сетевого пути (например, его нет на VPC), прокси-сервер все равно не сможет подключиться.)