Аутентификация между микросервисами в Кубернетесе

Question

У нас есть несколько микросервисов, реализованных на Java / Kotlin и Spring MVC, работающих в образах Tomcat. Эти сервисы предоставляют общедоступные API, которые аутентифицируются с помощью файлов cookie / сеансов пользователя. Они работают правильно.

Теперь мы хотели бы создать внутреннюю конечную точку, которая не была бы доступна ни за пределами GKE, ни через какую-то внутреннюю аутентификацию.

Какой будет хороший путь, особенно для Spring MVC и GKE?

EDIT:

Я бы хотел добиться проверки подлинности разных конечных точек на одном сервисе. Например:

• /public/ - без аутентификации
• /private/ - пользователь должен войти в систему
• /internal/ - только другие микросервисы могут получить доступ

Я бы предпочел реализовать такую ​​аутентификацию на уровне приложений, но я не уверен, что будет лучшим способом. Диапазон IP-адресов внутренних IP-адресов Google? Какой-то другой способ надежной идентификации абонента?

Может быть, моя идея плохая, если так, я буду рад изменить свое мнение.

Answer 1

Ваш вопрос не является конкретным GKE. Это в целом вопрос Кубернетса.

Я рекомендую вам выполнить поиск аутентификации в сервисе Kubernetes.

Есть много способов сделать это, включая использование собственной модели авторизации. Здесь может помочь одна функция - это ресурс Kubernetes NetworkPolicy (он похож на брандмауэры), вы можете узнать больше об этом здесь https://kubernetes.io/docs/concepts/services-networking/network-policies/ и посмотреть здесь несколько примеров: https://github.com/ahmetb/kubernetes-network-policy-recipes (Имейте в виду, что это брандмауэр, не аутентификация.)

Если вы хотите получить это автоматически, вы можете использовать Istio (https://istio.io)), который позволяет автоматически настраивать взаимный TLS между всеми вашими сервисами без каких-либо изменений кода. Istio также дает надежную идентификацию для каждой рабочей нагрузки. Вы можете использовать политики аутентификации Istio для установки аутентификации между вашими микроуслугами без изменения кода приложения , что действительно здорово: https://istio.io/docs/tasks/security/authn-policy/