Как настроить IAP для автономного веб-сервера Google Composer на GKE - PullRequest
0 голосов
/ 16 февраля 2020

Компания, в которой я работаю, имеет среду Composer в Google Cloud, и мне недавно пришлось создать наше собственное приложение для веб-сервера с самоуправлением в том же кластере GKE, поскольку на стандартном веб-сервере, который был предоставлен, возникли проблемы с тайм-аутом.

В любом случае, когда я выставлял этот веб-сервер через базовый вход c и без каких-либо ограничений доступа, я мог просто нормально подключиться к нему, используя сгенерированный внешний IP-адрес. Однако наша команда должна ограничить доступ к этому веб-серверу только определенным пользователям, и мы решили, что лучший способ сделать это - использовать IAP для ограничения доступа к указанным c учетным записям Google, как описано в этом документе: https://cloud.google.com/iap/docs/enabling-kubernetes-howto.

Я следовал инструкциям в приведенном выше документе, чтобы создать балансировщик нагрузки с поддержкой IAP, и когда я подключаюсь к веб-серверу через внешний IP-адрес, журналы балансировщика нагрузки в состоянии стека-драйвера, запрос был "handled_by_identity_aware_proxy" "Так что я думаю, что это перенаправлено. Но проблема в том, что браузер показывает «Этот сайт недоступен», и я не подключаюсь к веб-серверу.

У меня есть несколько подозрений относительно причины, и мне было интересно если кто-то может уточнить эти моменты:

  1. В приведенном выше документе говорится, что два требования для настройки IAP - это «доменное имя, зарегистрированное по адресу балансировщика нагрузки» и «код приложения для проверки». что все запросы имеют идентичность ". Мой первый вопрос: необходимо ли зарегистрированное доменное имя для IAP, у меня нет зарегистрированного доменного имени, но недостаточно ли внешнего IP-адреса, сгенерированного входом? А что означает документ под «кодом приложения для проверки идентичности всех запросов»? Означает ли это, что мне нужно создать скрипт в приложении веб-сервера для аутентификации пользователей? По этой причине я получаю сообщение об ошибке «Этот сайт недоступен» в моем браузере?

  2. На странице прокси-сервера с идентификационными данными на моей консоли Google отображается статус моего Бэкэнд-сервис отображается как «Предупреждение». Я подозреваю, что это связано с тем, что в моем проекте есть несколько правил брандмауэра, которые разрешают всем диапазонам IP-адресов иметь неограниченный доступ к кластеру GKE, в котором находится этот веб-сервер. Мой второй вопрос: ДОЛЖНЫ ли ВСЕ входящие в кластер запросы go через этот балансировщик нагрузки, или если есть определенные диапазоны ip, которые могут обойти балансировщик нагрузки, это все еще позволяет IAP работать, несмотря на очевидные угрозы безопасности? Или это причина, по которой вход не работает?

Большое спасибо за вашу помощь, ребята.

1 Ответ

0 голосов
/ 18 февраля 2020

1а. IAP работает через HTTPS, поэтому для подтверждения права собственности на регистрацию доменного имени требуется сертификат SSL. Без сертификата сайт может быть достигнут через внешний IP-адрес publi c, но он не будет работать вообще.

1b. Получение идентификатора пользователя позволяет вашему приложению проверить, что запрос поступил через IAP, и это необходимо настроить в вашем приложении. Вы всегда должны использовать некоторые механизмы: получить удостоверение пользователя с подписанными заголовками , с App Engine и Users API

Все запросы, поступающие в кластер, должны go через балансировщик нагрузки
...