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

Question

我是 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 但可以访问后端开发？
一些微服务需要与也在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 $

score 2 · Accepted Answer

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

对等身份验证

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

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

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

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

未设置模式时，将继承父范围的模式。未设置模式的 Mesh-wide peer 认证策略默认使用 PERMISSIVE 模式。

在这里也值得一看，因为 banzaicloud 在这里很好地描述了它。

您可以全局启用严格的 mtls 模式，也可以针对特定的命名空间或工作负载启用严格的 mtls 模式。

您可以使用 istio授权策略来做到这一点。

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、端口、协议、端点）。这些服此外，还可以使用workloadSelector 字段动态选择服务条目的端点。这些端点可以是使用 WorkloadEntry 对象或 Kubernetes pod 声明的 VM 工作负载。

istio 文档中有示例：

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

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

你也可以使用，这里istioctl x describe有更多关于它的信息。

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

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

1 回答 1

对等身份验证

Related

Reference