了解 kubernetes Pod 的 Istio AuthN 和 authz

Question

我对将 Istio 与 EKS 结合使用感到有些困惑。 我们有 2 个 spring boot 微服务，一个是 REST 服务提供者，另一个是消费者。 我们想使用 Istio 实现 Authn 和 authz。

为此： 1. 在提供者服务方面：我有一个 VirtualService，一个目标规则（声明 TLS 模式应该是 ISTIO_MUTUAL 传入流量），一个 AuthorizationPolicy 基本上将客户端服务帐户列入白名单。 我还有一个 AuthenticationPolicy 如下：

apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
  name: $APP_NAME-$FEATURE_NAME-authenticationpolicy
  namespace: $NAME_SPACE
spec:
  targets:
  - name: "$APP_NAME-$FEATURE_NAME"
  peers:
  - mtls:
      mode: STRICT

我的理解是，此策略不允许任何非 mtls 的传入流量。

现在我怀疑如何配置我的客户端 pod 以发送所有 mtls 传出流量。我知道我必须创建一个 ServiceAccount，它使用 Authz 策略在提供商端列入白名单。我更关心我的客户端 pod，因为我在这里我不确定如何在 pod 级别启用 mtls。 仅供参考，我不想在命名空间级别启用 mtls。我想使用 yaml 文件在 pod 级别执行此操作。

我对 Destination 规则、Authn 和 Authz 策略用法的理解是否正确？ Destination 规则、Authn 和 Authz 策略必须在服务提供商级别是否正确？ 客户端只需要启用 MTLS 即可成功进行通信？ 我一直在浏览 Istio 文档，但这是我有疑问的地方

Answer 1

我的理解是，此策略不允许任何非 mtls 的传入流量。

确实如此，如果您将 tls 模式设置为严格，则必须提供客户端证书，连接在 TLS 中。

---

我更关心我的客户端 pod，因为我不确定如何在 pod 级别启用 mtls。

有一篇关于如何使其工作的好文章，特别是部分

为两个服务之间的单个连接设置 mTLS

由于 Bookinfo 是 Istio 的 Hello World，我将使用它来解释如何设置从产品页面到详细信息服务的 mTLS，如上图所示。

这有两个部分：

安装一个 Policy 来告诉 Details 它想要接收 TLS 流量（仅限）：

apiVersion: authentication.istio.io/v1alpha1
kind: Policy
metadata:
  name: details-receive-tls
spec:
  targets:
  - name: details
  peers:
  - mtls: {}

2. 安装 DestinationRule 以告诉客户端（productpage）与详细信息交谈 TLS：

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: details-istio-mtls
spec:
  host: details.bookinfo.svc.cluster.local
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

以下是所涉及服务的图形表示以及前两个配置文档的适用位置。

现在，当您仔细查看上面的策略时，您将看到对等身份验证的条目

peers:
- mtls: {}

这意味着 TLS 验证是严格的，并且 Istio（或者更确切地说是 Pod 中的 Envoy 代理）需要 TLS 流量和有效的证书。 我们可以通过一个标志来获得许可模式：

peers:
- mtls: 
    mode: PERMISSIVE

---

Destination 规则、Authn 和 Authz 策略必须在服务提供商级别是否正确？

据我所知是的。

客户端只需要启用 MTLS 即可成功进行通信？

我不确定，因为 MTLS 在网格内工作，这取决于您的应用程序要求。

---

我想使用 yaml 文件在 pod 级别执行此操作。

有一个指向有关身份验证的istio 文档的链接，其中包括

• 使用启用双向 TLS 的 Istio sidecar 创建 HTTPS 服务
• 相互 TLS 深入探讨

另一个来自 github

• 为前端服务启用 mtls

或者您可以扩展网关的定义以支持双向 TLS。 通过删除其机密并创建新的机密来更改入口网关的凭据。 服务器使用 CA 证书来验证其客户端，我们必须使用名称 cacert 来保存 CA 证书。 您可以使用 cert-manager 生成客户端证书。

• https://istio.io/docs/tasks/traffic-management/ingress/secure-ingress-sds/#configure-a-mutual-tls-ingress-gateway
• https://istio.io/docs/tasks/traffic-management/ingress/ingress-certmgr/

---

我找到了一些可能有用的教程，请查看。

• 使用 Istio 管理服务之间的双向 TLS
• 授权
• 智威汤逊
• istio mtls,jwt,authn

---

如果您还有其他问题，请告诉我。

Answer 2

谢谢 JT97。这是我实现的

1) 对于身份验证，我为必须启用 MTLS 的传入请求实施了 Istio STRICT 身份验证策略。 Citadel 应该根据他们的证书来确定客户和服务提供商是否是他们声称的人。

2）对于授权，我在客户端创建了一个服务帐户，并在服务器端添加了一个授权策略，只将那些我想使用我的 REST 资源（PUT POST 等）的服务帐户列入白名单

3）我配置不同的一件事是目标规则。 理想情况下，它应该在客户端说我声明我的目的地规则提供者目的地是这个的客户端。与 ISTIO_MUTUAL。 在我看来，在提供者端声明目的地规则没有任何区别。

4.) 我已经在命名空间级别声明了目标规则。现在必须测试来自命名空间之外但在网格内的客户端。