Question

这是一个“原则上”的问题，我试图了解Istio中mTLS的实现方式，以及它如何与本来可以很好地支持mTLS的服务（例如gRPC）一起使用。

请考虑我有一个启用了“ mtls Anywhere”的集群。这样可以在特使代理之间的mTLS管道上有效地隧穿所有TCP连接，并且特使与服务之间的连接采用纯文本格式。

但是，有些服务需要至少TLS连接才能使特使代理；理想情况下是mTLS连接。其中之一是gRPC，它需要TLS才能使用其核心JWT身份验证：

https://grpc.io/docs/guides/auth.html#authenticate-with-google

因此，问题变为：

是否可以在原始服务本身通过mTLS加密的连接上使节代理“窥探”？理想情况下，使用Citadel提供的证书和密钥
是否可以通过一种新的身份验证方法来解决这个问题，该方法将忽略Istio的纯文本内容，因为它是纯文本格式的？

<3欢呼声

Answer 1

Istio试图解决的众多问题之一是将证书管理从应用程序层转移到sidecar容器中。我个人不知道使用Citadel管理应用容器中的证书的方法，至于“监听”，您可以尝试使用envoy filter进行烹饪，但是即使可以，这也是一种自定义解决方案会轻易断裂。不知何故，我认为这不会奏效，或者根本无法奏效。您的第一个问题/方法似乎走错了轨道。

不幸的是，我无法直接回答您的第二个问题，但是我短暂地参与了一个项目，该项目使用了JWT的gRPC微服务，该服务已由Istio验证，并且我们没有处理容器肯定。因此，在没有具体实现细节的情况下，我将说第二种选择。

这值得一提的是所使用的身份验证策略的示例。

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: {{ template "service.name" . }}
  labels:
    app: {{ template "service.name" . }}
    chart: {{ template "service.chart" . }}
    release: {{ .Release.Name }}
    heritage: {{ .Release.Service }}
spec:
  targets:
  - name: {{ template "service.name" . }}
  origins:
  - jwt:
      issuer: https://auth.company.com/
      jwksUri: https://auth-service.auth.svc.cluster.local:8008/keys/public
      audiences:
      - dGQVkdEluc3RhrmNps:CompanyApp:CompanyOrg
  principalBinding: USE_ORIGIN

如何在Istio中同时启用Mutual TLS和gRPC TLS，以便Istio可以收集指标，但是gRPC认为连接“安全”

1 个答案: