绕过 Istio 最终用户身份验证的 Web 浏览器答案

【问题标题】：Web browser bypasing Istio's end user authentification绕过 Istio 最终用户身份验证的 Web 浏览器
【发布时间】：2019-04-30 15:47:17
【问题描述】：

奇怪的事情正在发生！

我的集群中有一个 Keycloak 和一个简单的 Httpbin 应用程序。

我已设置 Istio 以使用 keycloak 对用户进行身份验证（如 Istio documentation 中所述）

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: auth-token
spec:
  targets:
    - name: httpbin
  origins:
    - jwt:
        issuer: "http://10.233.11.203/auth/realms/istio"
        jwksUri: "http://10.233.11.203/auth/realms/istio/protocol/openid-connect/certs"
  principalBinding: USE_ORIGIN

我尝试使用以下配置设置：

curl <IP_OF_HTTPBIN>

我收到Origin authentification failed，这是完全正常，因为我没有提供任何访问令牌。

现在，当我使用我的 网络浏览器 访问应用程序时，我预计会出现某种错误，但它不能正常工作...

我的问题是它不应该工作。浏览器未获得更多授权，然后 curl 命令...

有关信息，我使用 kubectl port-forward 和反向代理从浏览器访问应用程序。

【问题讨论】：

标签： authentication keycloak istio

【解决方案1】：

kubectl port-forward 将流量从您机器的 localhost 直接转发到 k8 pod，绕过所有 Istio 身份验证。当您针对 httpbin 的公共 ip 运行 curl 时，请求由 Istio 的网关处理并验证 jwt 令牌。

Istio 的 jwt 验证发生在下游并且独立于您的 pod。如果您直接点击您的 pod，则出于开发目的，您故意绕过最终用户身份验证。这使您可以独立于服务的身份验证方式来开发服务。

【讨论】：

感谢您的回答！我通过网关得到它，让 Istio 处理安全性。但是我仍然不明白的是 curl 集群 IP 和使用端口转发之间的区别。在您的第一段中，您将 port-forward 与 curling 通过网关 进行比较。但是我的询问是关于port-forward 和curl 直接使用集群IP（没有网关）之间的区别。虽然也许我没明白你的意思：-p
我现在理解的是，你不能期望从外部连接与使用 Kubernetes API 的结果相同，因为你实际上是直接连接到 pod。有关此堆栈线程 [1] 的更多信息。 _____________ [1]:stackoverflow.com/questions/51468491/…

【解决方案2】：

我找到了解决此问题的方法...如果我使用网关访问应用程序，那么浏览器也会获得 Origin authentification failed。

但这并不能解释为什么浏览器首先绕过了 istio 的策略，而 curl 却没有......

【讨论】：