Блог

Предварительные требования

У меня есть две облачные службы a frontend и a backend . Интерфейс написан на Vue.js/Nuxt.js и поэтому использует серверную часть узла. Серверная часть написана на Kotlin с загрузкой Spring.

Проблема

Чтобы иметь аутентифицированную внутреннюю связь между интерфейсом и серверной частью, мне нужно использовать токен thttps://cloud.google.com/run/docs/authenticating/service-to-service#javahat извлекается с метасервера Google. Это задокументировано здесь: https://cloud.google.com/run/docs/authenticating/service-to-service#java

Я все это настроил, и это работает.

Для моего второго уровня безопасности я интегрировал поставщика аутентификации Auth0 как в мой интерфейс, так и в мой сервер. В моем интерфейсе пользователь может войти в систему. Интерфейс вызывает внутренний API. Поскольку только авторизованные пользователи должны иметь возможность вызывать серверную часть, я интегрировал Spring Security для защиты конечных точек серверного API.

Теперь серверная часть проверяет, действительны ли токены запроса вызывающего абонента, прежде чем разрешить его передачу в логику API.

Однако эта теория не работает. И это просто потому, что я делегирую вызовы API через серверный прокси-сервер узла. Однако логика прокси-сервера уже применяет токен к запросу к серверной части; это токен метасервера Google. Итак, позвольте мне проиллюстрировать это:

Client (Browser) -> API Request with Auth0 Token -> Frontend Backend Proxy -> Overriding Auth0 Token with Google Metaserver Token -> Calling Backend API

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

Вопрос

Из-за того, что я не смог найти никаких статей об этой проблеме, я задаюсь вопросом, не потому ли это, что я делаю это в основном неправильно.

Что мне нужно сделать, чтобы иметь действительную связь службы облачного запуска с сервисом (гарантируемую токеном метасервера), но в то же время иметь защищенный серверный API с авторизацией Auth0?

Я вижу два обходных пути, чтобы это произошло:

• Авторизуйте вызов API в логике серверного прокси-сервера узла
• Сделайте серверную службу общедоступной, поэтому токен метасервера не нужен

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

Хорошо, я нашел третий способ иметь де-факто внутреннюю службу для обслуживания связи.

Чтобы исключить аутентификацию токена мета-сервера, но при этом ограничить доступ из Интернета, я сделал следующее для своей backend службы облачного запуска:

Это делает службу доступной из Интернета, однако вход препятствует доступу к службе посторонним лицам. Служба доступна без IAM, но только для внутреннего трафика.

Итак, теперь я frontend вызываю backend API через серверный прокси-сервер узла. Несмотря frontend на то, что серверная часть узла и backend служба находятся в некоторой степени «в облаке», они не используют одну и ту же «внутреннюю сеть». Фактически frontend запросы на серверную часть узла будут перенаправляться через выход в Интернет и вызывать backend службу точно так же, как это сделал бы любой другой пользователь Интернета.

Чтобы заставить его работать «так, как будто он поступает из внутреннего», вам нужно сделать что-то похожее на VPN, но это называется VPC (виртуальное частное облако). И, к счастью, это очень просто. Просто создайте соединитель VPC в GCP.

НО помните о создании так называемого бессерверного доступа VPC (Connector). Объясняется здесь: https://cloud.google.com/vpc/docs/serverless-vpc-access

После создания бессерверного доступа VPC вы можете выбрать его в настройках «Подключение» облачной службы запуска. Для backend службы его можно просто выбрать. frontend Однако для службы важно выбрать второй вариант:

По крайней мере, это важно в моем случае, поскольку я вызываю backend службу по назначенному URL-адресу службы вместо частного IP.

После всего, что сделано, мой токен JWT из the frontend успешно доставлен в backend API без перезаписи токеном метасервера.