如何在 kubernetes 中调试与 istio 的 mTLS 通信？答案

【问题标题】：How to debug mTLS communication with istio in kubernetes?如何在 kubernetes 中调试与 istio 的 mTLS 通信？
【发布时间】：2021-04-19 07:14:01
【问题描述】：

我是 Istio 的新手，因此这可能是一个简单的问题，但我对 Istio 有一些困惑。我正在为 k8s 使用 Istio 1.8.0 和 1.19。很抱歉有多个问题，但如果你能帮助我，我将不胜感激阐明最佳方法。

在我注入 Istio 后，我想我无法直接在 pod 内访问服务到服务，但正如您在下面看到的我可以。也许我有误解，但这是预期的行为吗？同时，如何调试服务是否通过特使代理与 mTLS 相互通信？我正在使用STRICT 模式，我是否应该在运行微服务的命名空间部署对等身份验证以避免这种情况？
```
 kubectl get peerauthentication --all-namespaces
 NAMESPACE      NAME      AGE
 istio-system   default   26h
```
如何限制流量让我们说 api-dev 服务不应该访问 auth-dev 但可以访问 backend-dev？
一些微服务需要与数据库通信，它也在database 命名空间中运行。我们还有一些我们不想注入 istio 的也使用相同的数据库？那么，数据库是否也应该部署在我们进行 istio 注入的同一个命名空间中？如果是，那是否意味着我需要为其余服务部署另一个数据库实例？

    $ kubectl get ns --show-labels
    NAME              STATUS   AGE    LABELS
    database          Active   317d   name=database
    hub-dev           Active   15h    istio-injection=enabled
    dev               Active   318d   name=dev


    capel0068340585:~ semural$ kubectl get pods -n hub-dev
    NAME                                     READY   STATUS    RESTARTS   AGE
    api-dev-5b9cdfc55c-ltgqz                  3/3     Running   0          117m
    auth-dev-54bd586cc9-l8jdn                 3/3     Running   0          13h
    backend-dev-6b86994697-2cxst              2/2     Running   0          120m
    cronjob-dev-7c599bf944-cw8ql              3/3     Running   0          137m
    mp-dev-59cb8d5589-w5mxc                   3/3     Running   0          117m
    ui-dev-5884478c7b-q8lnm                   2/2     Running   0          114m
    redis-hub-master-0                        2/2     Running   0           2m57s
    
    $ kubectl get svc -n hub-dev
    NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
    api-dev                ClusterIP   xxxxxxxxxxxxx      <none>        80/TCP    13h
    auth-dev               ClusterIP   xxxxxxxxxxxxx      <none>        80/TCP    13h
    backend-dev            ClusterIP   xxxxxxxxxxxxx      <none>        80/TCP    14h
    cronjob-dev            ClusterIP   xxxxxxxxxxxxx      <none>        80/TCP    14h
    mp-dev                 ClusterIP   xxxxxxxxxxxxx      <none>        80/TCP    13h
    ui-dev                 ClusterIP   xxxxxxxxxxxxx      <none>        80/TCP    13h
    redis-hub-master       ClusterIP   xxxxxxxxxxxxx      <none>        6379/TCP  3m47s
    


----------


    $ kubectl exec -ti ui-dev-5884478c7b-q8lnm -n hub-dev sh
    Defaulting container name to oneapihub-ui.
    Use 'kubectl describe pod/ui-dev-5884478c7b-q8lnm -n hub-dev' to see all of the containers in this pod.
    /usr/src/app $ curl -vv  http://hub-backend-dev
    *   Trying 10.254.78.120:80...
    * TCP_NODELAY set
    * Connected to backend-dev (10.254.78.120) port 80 (#0)
    > GET / HTTP/1.1
    > Host: backend-dev
    > User-Agent: curl/7.67.0
    > Accept: */*
    >
    * Mark bundle as not supporting multiuse
    < HTTP/1.1 404 Not Found
    < content-security-policy: default-src 'self'

    <
    <!DOCTYPE html>
    <html lang="en">
    <head>
    <meta charset="utf-8">
    <title>Error</title>
    </head>
    <body>
    <pre>Cannot GET /</pre>
    </body>
    </html>
    * Connection #0 to host oneapihub-backend-dev left intact
    /usr/src/app $

【问题讨论】：

标签： kubernetes istio servicemesh

【解决方案1】：

根据documentation，如果您使用STRICT mtls，那么工作负载应该只接受加密流量。

对等身份验证

对等身份验证策略指定 Istio 对目标工作负载实施的双向 TLS 模式。支持以下模式：

PERMISSIVE：工作负载接受双向 TLS 和纯文本流量。当工作负载没有迁移时，此模式最有用 sidecar 不能使用双向 TLS。迁移工作负载后 sidecar 注入，您应该将模式切换为 STRICT。

STRICT：工作负载只接受双向 TLS 流量。

禁用：禁用双向 TLS。从安全角度来看，您除非您提供自己的安全性，否则不应使用此模式解决方案。

模式未设置时，继承父作用域的模式。 Mesh-wide peer authentication policy with unset mode 默认使用 PERMISSIVE 模式。

也值得一看 here，因为它在这里被 banzaicloud 描述得非常好。

您可以启用严格的 mtls 模式 globally，也可以启用特定的 namespace 或 workload。

您可以使用 istio Authorization Policy 来做到这一点。

Istio 授权策略启用对网格中工作负载的访问控制。

有一个例子。

以下是将操作设置为“拒绝”以创建拒绝策略的另一个示例。它拒绝从“dev”命名空间到“foo”命名空间中所有工作负载的“POST”方法的请求。

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: httpbin
 namespace: foo
spec:
 action: DENY
 rules:
 - from:
   - source:
       namespaces: ["dev"]
   to:
   - operation:
       methods: ["POST"]

您可以在不注入数据库的情况下设置数据库，然后使用 ServiceEntry 对象将其添加到 Istio 注册表中，以便它能够与其余的 istio 服务进行通信。

ServiceEntry 允许将额外的条目添加到 Istio 的内部服务注册表中，以便网格中自动发现的服务可以访问/路由到这些手动指定的服务。服务条目描述了服务的属性（DNS 名称、VIP、端口、协议、端点）。这些服务可能在网格外部（例如，Web API）或网格内部服务，它们不属于平台的服务注册表（例如，一组与 Kubernetes 中的服务通信的 VM）。此外，还可以使用workloadSelector 字段动态选择服务条目的端点。这些端点可以是使用 WorkloadEntry 对象或 Kubernetes pod 声明的 VM 工作负载。在单个服务下同时选择 pod 和 VM 的能力允许将服务从 VM 迁移到 Kubernetes，而无需更改与服务关联的现有 DNS 名称。

在 istio 文档中有示例：

回答您关于如何调试 mtls 通信的主要问题

最基本的测试是尝试从未注入的 Pod 调用到注入的 Pod，例如使用 curl。有 istio documentation 关于那个。

您也可以使用istioctl x describe，更多信息here。

不确定curl -vv http://hub-backend-dev 有什么问题，但由于它是 404，我怀疑这可能是您的 istio 依赖项的问题，例如错误的虚拟服务配置。

【讨论】：

感谢您的详细解释.. 可能是什么原因 global one 不适合我.. 因为我希望在启用 peerauth 后我不应该访问 pod 到 pod
@semural 抱歉回复晚了，是的，如果没有注入 pod，您不应该这样做。您可以添加 PeerAuthentication 的 yaml 定义吗？我将从documentation 开始检查它是否适用于睡眠和 httpbin 服务，如果它可以正常工作，那么我会说这可能是特定应用程序或集群的问题。