是否可以使用 RequestAuthentication 和 AuthenticationPolicy 进行微服务到微服务的通信答案

【问题标题】：Is it possible to use RequestAuthentication and AuthenticationPolicy for microservice to microservice communication是否可以使用 RequestAuthentication 和 AuthenticationPolicy 进行微服务到微服务的通信
【发布时间】：2022-01-13 05:55:57
【问题描述】：

我们最近在我们的 kubernetes 集群上设置了 istio，并试图看看我们是否可以使用 RequestAuthentication 和 AuthenticationPolicy 使我们能够只允许命名空间 x 中的 pod 与命名空间 y 中的 pod 通信，前提是它具有有效的 jwt 令牌.

我在网上看到的所有示例似乎都只通过网关申请最终用户身份验证，而不是内部 pod 到 pod 通信。

我们尝试了几种不同的选择，但都没有成功。

我们可以让 AuthenticationPolicy 使用“from”来处理 pod 到 pod 的流量，源是命名空间 x 中 pod 的 IP 地址：

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"]

当我们为 jwt 添加 when 块时它不起作用：

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: ["*"]

提前致谢！

【问题讨论】：

是的，有可能。这对您的环境、正在使用的 JWT 等非常重要。我建议您打开 rbac 范围日志以在特使代理中进行调试，并查看您从 JWT 获得的过滤器元数据。也许它根本不匹配 RequestAuthentication 资源中的颁发者。如果是，那么您应该会看到过滤器元数据，其中显示了您可以应用 AuthZ 策略的信息。
您使用的是哪个 Istio 和 Kubernetes 版本？
您使用的是哪个 Istio 和 Kubernetes 版本？你用的是哪个installation configuration profile？您是如何设置集群的——一些裸机或云提供商解决方案？此信息对于重现您的问题很重要。您的 pod 如何向其他命名空间中的 pod 发出请求？
@rinor 关于增加 rbac 日志记录的建议有助于确定我们的 keycloak 设置存在的问题。当我们修复该问题后，一切都按预期工作。
@gdix0n 我添加了评论作为答案，因为人们可能不会阅读 cmets 认为它没有得到回答。

标签： kubernetes istio istio-sidecar istio-gateway istio-operator

【解决方案1】：

是的，可以同时使用授权策略和请求身份验证。

但是调试相当困难，因为很多都基于您的环境和正在使用的 JWT，等等。

为了解决这类问题，我首先将 rbac 范围的日志设置为调试服务特使代理。在 rbac 调试日志中，您将看到从 JWT 中提取并存储到过滤器元数据中的数据。你会经常发现的是：

过滤器元数据中的颁发者可能与 RequestAuthentication 资源中的颁发者不匹配，等等。

在此处了解有关日志记录范围的更多信息https://istio.io/v1.12/docs/ops/diagnostic-tools/component-logging/#logging-scopes

【讨论】：