Блог

Главная - Вопросы по программированию - Можно ли использовать RequestAuthentication и AuthenticationPolicy для связи между микросервисами

Можно ли использовать RequestAuthentication и AuthenticationPolicy для связи между микросервисами

#kubernetes #istio #istio-sidecar #istio-gateway #istio-operator

#kubernetes #istio #istio-sidecar #istio-шлюз #istio-оператор

Вопрос:

Недавно мы настроили istio в нашем кластере kubernetes и пытаемся выяснить, можем ли мы использовать RequestAuthentication и AuthenticationPolicy, чтобы разрешить pod в пространстве имен x взаимодействовать с pod в пространстве имен y только тогда, когда у него есть действительный токен jwt.

Все примеры, которые я видел в Интернете, похоже, применяются только для аутентификации конечного пользователя через шлюз, а не для внутренней связи pod-pod.

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

Мы можем заставить AuthenticationPolicy работать для трафика pod-pod, используя «from», а источником является IP-адрес pod в пространстве имен x:

 apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
 name: "request-jwt"
 namespace: y
spec:
  jwtRules:
  - issuer: "https://keycloak.example.com/auth/realms/istio"
    jwksUri: "https://keycloak.example.com/auth/realms/istio/protocol/openid-connect/certs"
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "jwt-auth"
  namespace: y
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        ipBlocks: ["10.43.5.175"]

Когда мы добавляем блок when для jwt, это не работает:

 apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
 name: "request-jwt"
 namespace: y
spec:
  jwtRules:
  - issuer: "https://keycloak.example.com/auth/realms/istio"
    jwksUri: "https://keycloak.example.com/auth/realms/istio/protocol/openid-connect/certs"
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "jwt-auth"
  namespace: y
spec:
  action: ALLOW
  rules:
  - from:
    - source:
        ipBlocks: ["10.43.5.175"]
    when:
     - key: request.auth.claims[iss]
       values: ["https://keycloak.example.com/auth/realms/istio"]

Также пробовал это, но, похоже, тоже не работает:

 apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
 name: "request-jwt"
 namespace: y
spec:
  jwtRules:
  - issuer: "https://keycloak.example.com/auth/realms/istio"
    jwksUri: "https://keycloak.example.com/auth/realms/istio/protocol/openid-connect/certs"
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: "deny-invalid-jwt"
  namespace: y
spec:
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]

Заранее спасибо!

Комментарии:

1. Да, это возможно. Это очень важно для вашей среды, используемого JWT и т. Д. Я бы посоветовал вам включить журналы с областью действия rbac для отладки в прокси-сервере envoy и просмотреть метаданные фильтра, которые вы получаете из своего JWT. Возможно, он вообще не соответствует отправителю в ресурсе RequestAuthentication. Если это так, то вы должны увидеть метаданные фильтра, которые показывают информацию о том, что вы можете применять политики аутентификации.

2. Какую версию Istio и Kubernetes вы используете?

3. Какую версию Istio и Kubernetes вы используете? Какой профиль конфигурации установки вы использовали? Как вы настроили свой кластер — какое-то простое решение или решение облачного провайдера? Эта информация важна для воспроизведения вашей проблемы. Как ваш модуль отправляет запрос к модулю в другом пространстве имен?

4. Предложения @rinor по увеличению протоколирования для rbac помогли выявить проблему с нашей настройкой keycloak. Когда мы исправили эту проблему, все работает так, как ожидалось.

5. @gdix0n Я добавил комментарий в качестве ответа, поскольку люди могут не читать комментарии, думая, что на них нет ответа.

Ответ №1:

Да, можно использовать как политики авторизации, так и запрашивать аутентификации.

Но отладка довольно сложна, потому что многое зависит от вашей среды и используемого JWT, и так далее.

Для устранения подобных проблем я бы начал с настройки журналов с областью действия rbac для отладки для прокси-сервера services envoy. В журналах отладки rbac вы увидите данные, извлеченные из JWT и сохраненные в метаданных фильтра. Часто вы обнаружите, что:

  • Эмитент в метаданных фильтра может не совпадать с тем, который указан в ресурсе RequestAuthentication и т. Д.

Подробнее об областях ведения журнала здесь https://istio.io/v1.12/docs/ops/diagnostic-tools/component-logging/#logging-scopes

Метки: