确保数据安全

Mendix 私有云通过多种方式实施 TLS 来确保数据安全：

• “入口 TLS” – 用于加密 Web 浏览器（或其他 HTTP 客户端）与 Mendix 运行。
• “客户端 TLS” – 客户端证书（您可以在运行时中配置它们）由远程服务器用来验证 Mendix 运行时。同时， Mendix 运行时使用远程服务器提供的证书来验证其身份。
• “TLS 信任” – 用于在连接到数据库、文件存储或注册表时信任私有根 CA。受信任的根证书可验证远程服务器的真实性，并在连接到其他外部服务时使用（例如，在 Mendix 应用程序）。

那么，我们为什么需要 Service Mesh？它到底是什么？我们先来了解一下安全通信的基础。

什么是 TLS？

TLS （传输层安全性）是一种加密协议，通过加密数据、验证身份和维护数据完整性来确保两个设备在潜在不受信任的网络上的安全通信。

主要组成部分有：

• 两个密钥，称为公钥和私钥。
• 两个密钥均有一个设定的有效期。
• 通过公钥加密的数据只能由其私钥解密。
• 通过私钥加密的数据只能由其公钥解密。

TLS 如何工作？

简而言之，服务器拥有 TLS 证书和密钥对。然后，流程如下：

1. 客户端连接到服务器。
2. 服务器发送其 TLS 证书。
3. 客户端验证服务器的证书（TLS 握手）。
4. 客户端和服务器通过加密的 TLS 连接交换信息。

这里的关键是要理解在 TLS 中，只有客户端验证服务器身份。

好的，那么什么是 mTLS？

相互传输层安全 (mTLS) 建立在 TLS 之上。该过程非常相似，但客户端需要自带证书和密钥对。换句话说，客户端和服务器会相互验证身份。

mTLS 的工作原理如下：

1. 客户端连接到服务器。
2. 服务器发送其 TLS 证书。
3. 客户端验证服务器的证书（TLS 握手）。
4. 客户端发送其 TLS 证书。
5. 服务器验证客户端的证书（再次 TLS 握手）。
6. 然后，通过安全通道建立连接。

那么，什么是服务网格？

服务网格是在微服务架构中运行的网络基础设施。其主要目标是增强安全性并管理在这些服务之间移动的数据加密。

出于本文的目的，我将仅关注服务网格可以提供的众多功能中的三个：

• 服务到服务加密： 服务网格使用 TLS 和 mTLS 来加密和验证这些服务间通信。
• 证书管理： 服务网格通过自动化证书颁发、轮换和分发简化了 TLS 证书的管理。
• 零信任网络： 服务网格通常采用“零信任”方法，这意味着默认情况下服务之间的通信不受信任。TLS 和 mTLS 在这种方法中起着至关重要的作用，因为它们可以验证通信方的身份并加密数据，即使在受信任的网络中也是如此。

服务网格 Mendix 私有云

对于本次演示， AWS EKS 的官方 Terraform 部署模块 用于配置 Kubernetes 集群。因此，配置的基础架构从一开始就提供以下关键功能：

• A Mendix 在名为“mendix”的命名空间内配置操作员和代理。
• 在以下位置建立了安全连接 (TLS) Mendix 应用程序和基本组件，如数据库、存储和注册表。
• 负载均衡器与 Mendix 工作量。

因此，这里的目标是启用服务网格来保证零信任网络：所有 pod 都将通过相互 TLS 以安全的方式与所有内部 Kubernetes 服务进行通信。

还有什么？是的，我们还将在“网格”中包含 Ingress 控制器，以保护路由到 Pod 的所有外部流量。

听起来很令人兴奋？

可能令人困惑？

也许一些图表会有所帮助：

这就是我们现在的状况……

注意： Mendix 代理和开发者门户仅适用于连接模式

…这是我们期望的最终状态：

从2.5版本开始， Mendix Operator 与 Istio 和 Linkerd 兼容，适用于 Connected 和 Standalone 产品。

为了简单起见，我将仅探索并启用 Linkerd，但 Istio 的过程非常相似。

安装 Linkerd

按照 官方文件 安装：

• Linkerd CLI，取决于您的操作系统。
• Linkerd CRD
• Linkerd 扩展（强烈推荐 viz 和 dashido）

Mendix 用于私有云网格注入

一个非常酷的功能 Mendix 对于私有云来说，网格“注入”可以按环境启用（非常适合快速验证测试或隔离），也可以为整个命名空间启用。

请参阅下图以了解如何启用 Linkerd，但请查看官方文档 保持联系 金益辉 独立 ，了解更多详情。

为一个环境启用 Linkerd

首先，将直接从开发者门户为名为 terrapp1 的应用程序启用 Linkerd 注释。

如您所见，一旦启用并应用更改， Mendix Pod 将重新启动，并且 Linkerd 仪表板会检测到注释并将 Pod 标记为网格化：

太好了，现在我们的第一个应用程序已成功添加到 Linkerd 并且 mTLS 已开始运行。

为整个命名空间启用 Linkerd

让我们进入下一步，即添加整个 Mendix 命名空间到网格，保护操作员、代理和应用程序之间的连接！

如以下视频所示，我们需要：

1. 注释整个命名空间（称为“mendix”）以进行 Linkerd 注入
2. 通过查看配置确认注释已添加到命名空间。

注意：如果 Pod 未自动添加到网格中，建议缩小和扩大每个部署：

• • kubectl 规模部署 mendix-operator —replicas=0
  • kubectl 规模部署 mendix-agent —replicas=0
  • 重复上述操作，添加 replicas=1

哇哦！现在我们离零信任网络目标越来越近了。让我们从开发者门户部署一个新应用程序，看看它是如何自动添加到网格中的！

将 NGINX 入口添加到网格

在大多数客户设置中， TLS 终止 在 Kubernetes 集群中的入口控制器中配置。简单来说，这意味着外部入站流量以加密（TLS）形式到达入口服务，并以未加密（纯 http）形式提供给 Pod。

我们的最后一步是确保入口控制器与所有服务之间的 mTLS 连接。 Mendix 命名空间。为此，我们需要：

• 将 NGINX 入口控制器部署添加到网格中。 按照说明操作 取决于您如何在集群中安装 NGINX（helm 或 YAML）。
• 确保添加 thenginx.ingress.kubernetes.io/service-upstream 正确注释以确保控制器不使用 Pod 端点，而是使用服务的 Cluster IP 和端口。

现在是时候确认一旦 Nginx 添加到网格中，到 pod 的所有流量都使用 mTLS：

NGINX 已实现网格化，并安全地将流量发送到 Mendix 应用领域

结语

强大的服务网格架构的重要性怎么强调也不为过，它在微服务环境中提供细粒度的可见性、安全通信和策略实施的能力对于保护数据和系统至关重要。

利用 Mendix 私有云与 Istio 和 Linkerd 的无缝集成使组织能够实现敏捷性和安全性的和谐融合。 Mendix的快速开发能力与服务网格的严格安全措施相得益彰，使企业能够在不损害防御态势的情况下进行创新。

在这个威胁不断演变的时代，服务网格和 Mendix 私有云体现了前瞻性的信息安全方法。

快乐地啮合！