服务网格的简化替代方案有哪些?

开发
在这篇文章中,我们提出了在投资服务网格之前要考虑的替代方案。对于服务网格最流行的好处中的每一个,我们将展示根据我们的经验更接近管理员已经熟悉的替代方案。

服务网格是一项热门技术,有时甚至被吹捧为微服务成功的必要条件。但是,与许多抽象一样,服务网格可以节省时间,但不会节省学习时间。事实上,许多小型平台团队对服务网格增加的复杂性感到不知所措,尤其是在涉及到长时间的操作时。

很自然地会问一个问题:额外的复杂性真的超过了好处吗?

在这篇文章中,我们提出了在投资服务网格之前要考虑的替代方案。服务网格最流行的好处是:

  • 验证;
  • 入口加密;
  • 集群内网络加密;
  • 通讯隔离。

对于这些好处中的每一个,我们将展示根据我们的经验更接近管理员已经熟悉的替代方案。对于专业知识或平台工程带宽稀缺的组织,这些可能更具吸引力。

在某些情况下,您将需要服务网格,例如当您需要跨多个 Kubernetes 集群的安全 Pod 到 Pod 通信时。通过排除不能满足您需求的解决方案,您将进一步说服自己为什么选择服务网格开始。

Service Mesh 优势 1 - 使用 OAuth2-proxy 进行身份验证

许多应用程序团队需要在他们的微服务前面添加一个身份验证层。例如,完全实现 OAuth2 或 OpenID 涉及相当多的跳转。与其编写大量样板代码(这与应用程序非特定和非业务差异化相比),团队更愿意“某物”只是将具有正确声明的 JWT 令牌交给他们的应用程序,以便专注于特定于应用程序的访问控制。

我们之前写过关于如何将 Istio 与 OAuth2-proxy 集成以实现这一目标的博客。但是,如果这是您从 Istio 中唯一需要的东西,那么采用它可能有点过头了。

服务网格的替代方案:Nginx Ingress Controller

让我举例说明一个我认为更简单的解决方案,尤其是对于已经使用 Nginx 的团队。如果你只需要一些好的 oauth2-proxy,Nginx Ingress Controller 很容易与之集成。只需使用 auth-url 注释,控制器将完成其余的工作。下图说明了这是如何工作的。

图片

我认为这个解决方案更简单的原因是它只会影响流量进入 Kubernetes 集群的方式。Pod 到 Pod 的通信和以前一样工作。

如果您熟悉 Nginx,但害怕 Ingress Controller 在其周围添加的自动化,您可以通过键入以下内容直接检查 Nginx 的配置方式:

kubectl exec -ti \
-n ingress-nginx \
$(kubectl get pod \
-n ingress-nginx \
-l app.kubernetes.io/component=controller \
-o name \
| head -1 \
) \
-- \
cat /etc/nginx/nginx.conf

默认情况下,您的应用程序不会获得 JWT 令牌。为了确保您的应用程序获得细粒度访问控制的声明,您必须做两件事:

  • 首先,将--set-authorization-header命令行选项添加到 oauth2-proxy:这可确保 oauth2-proxy 生成 HTTP 授权标头。
  • 其次,将以下注释添加到您的 Ingress:nginx.ingress.kubernetes.io/auth-response-headers: “authorization” 。这可确保 Nginx 入口控制器将 HTTP 授权标头从 oauth2-proxy 转发到您的应用程序。

如果您需要更多详细信息,可以在此处找到现成的代码片段。

  • ​https://github.com/elastisys/compliantkubernetes/blob/main/user-demo/deploy/oauth2-proxy.yaml
  • https://elastisys.io/compliantkubernetes/user-guide/network-model/#ingress​

Service Mesh 优势二:入口加密

许多法规要求对不受信任网络上的网络流量进行加密。例如,PCI-DSS 要求 4 规定:“通过在开放的公共网络上加密来传输持卡人数据。” GDPR 和瑞典医疗保健(“Behandling av personuppgifter iöppna nät”“通过开放网络处理个人数据”)包含类似规定。

解决方案很简单:添加 TLS 终止。但是,TLS 终止不是业务差异化,也不是特定于应用程序的。理想情况下,平台应该“做它”。我经常看到团队仅针对这一功能采用服务网格,但还有一种更简单的替代方案。

服务网格的替代品:Cert-manager

您可以安装cert-manager,创建 ClusterIssuer 并通过注解使用该 ClusterIssuer 配置您的 Ingress。Cert-manager 将发挥与 LetsEncrypt 对话的魔力,提供 TLS 证书并在其到期前轮换它。

图片这在上图和相同的即用型代码片段中进行了说明。请参阅cert-manager.io/cluster-issuer注释。

Service Mesh 优势三:集群内网络加密

为一些争议做好准备。

我经常看到组织添加服务网格,因为 mTLS 和 Pod 到 Pod 加密很酷,并且可能是某些法规要求的。这是我对这个话题的看法。

首先,您很少(如果有的话)需要 Pod 到 Pod 加密。如上所述,PCI-DSS 和瑞典医疗保健都只需要对开放(即不受信任)网络进行加密。我经常听到团队争论 Pod 到 Pod 加密“以防万一”底层网络不受信任。如果您不能信任您的基础设施提供商,请更换提供商。再多的加密都不会阻止他们在内存中未加密时访问您的数据。

其次,假设您确实需要集群内加密。例如,您希望将 Kubernetes 集群扩展到通过不受信任的网络连接的两个数据中心。或者,您希望避免与两个数据中心之间的网络提供商签署另一个 GDPR 风格的数据保护协议 (DPA)。

服务网格的替代方案:CNI 级加密

在这种情况下,只需在您的容器网络接口 (CNI) 提供程序中启用 WireGuard 或 IPsec。这样就达到了加密网络流量Node-to-Node的效果。至少Calico和Flannel对此有支持。例如,如果您使用 Kubespray 设置 Calico,只需添加:

calico_wireguard_enabled: true

Service Mesh 的优势四:网络通信的隔离

服务网格带来了另一个特性:它们为每个 Pod 赋予一个身份,然后通过相互身份验证 (mTLS) 实施基于身份的访问控制。这带来了两个好处:首先,您的 Pod “不要与陌生人交谈”,这有助于使某些漏洞更难被利用,例如臭名昭著的Log4Shell。其次,它减少了爆炸半径:如果 Pod 被闯入,攻击者会发现很难横向移动。

服务网格的替代方案:NetworkPolicies

但是使用 NetworkPolicies 可以更简单、更标准化地实现相同的好处。它们就像容器化世界中的防火墙规则或安全组。由于 Pod 在每次部署时都会更改 IP 地址,因此 NetworkPolicies 本质上会将 Pod 身份转换为基于 IP 的防火墙规则,由 Linux 内核强制执行。

NetworkPolicy 由两部分组成:选择器和规则。选择器选择 NetworkPolicy 应用于哪些 Pod,匹配 Pod 标签或命名空间标签。规则指定允许进出所选 Pod 的入口和出口流量。可以设置安全措施以确保每个 Pod 都由 NetworkPolicy 选择。

在某些组织中,网络安全和应用程序安全是不同团队的责任。这可以通过 NetworkPolicies 和 Kubernetes RBAC 在技术上强制执行。只有网络团队被授予编辑 NetworkPolicies 的权限,而应用程序团队仅被授予在选定的命名空间中部署的权限。

最后一条建议:将命名空间视为“内部 API”。由于命名空间最终成为集群内 DNS 名称的一部分,因此最好通过它提供的服务(例如,“auth”、“database”、“licensing”)来命名命名空间,而不是团队名称(“team-green ”、“team-yellow”等)。这种做法还简化了网络安全团队设置 NetworkPolicies 的过程。

结论

简单性和可理解性是安全的关键。虽然安全网格带来了巨大的好处,但在采用它们之前请考虑更简单的替代方案。我的经验是网络和网络安全已经足够复杂。添加另一层可能会使您的平台团队不堪重负,并给他们带来“待命焦虑”。

当然,有许多出色的服务网格特性缺乏更简单的替代方案,例如多集群安全通信和联合网络可观察性。如果您确实需要更高级的功能,我们希望这篇博文可以帮助您做出明智的决定并接受新增的技术。

Kubernetes 网络和服务网格都在快速发展。就在最近几个月,Calico 添加了一个 eBPF 数据平面,并且 Istio 被捐赠给了 CNCF。此类事件可以有利于决策者决定倾向于采用或不采用服务网格。 

责任编辑:赵宁宁 来源: 云原生技术爱好者社区
相关推荐

2019-08-29 08:00:00

微服务架构服务网格

2022-09-06 10:46:34

服务网格可观测性微服务

2022-08-09 08:00:00

服务网格云原生工具

2023-06-18 19:21:04

技术架构服务网格

2022-11-24 14:21:27

微服务ISTIO

2020-11-15 23:48:57

服务网格微服务网络网络技术

2022-05-16 08:00:00

服务网格架构Kuma

2020-01-07 09:25:02

服务网格微服务Kubernetes

2020-07-13 07:00:03

微服务服务网格架构

2020-08-26 05:45:40

服务网格DevOps开发

2020-10-21 13:31:53

服务网格开源微服务

2021-04-25 08:48:36

Traefik mes服务网格Kubernetes集

2021-08-27 11:42:51

Nacos云原生阿里云

2021-04-02 22:00:50

服务网格微服务

2020-11-30 13:50:13

服务网格微服务数据

2022-08-02 16:37:32

服务网格网络服务

2019-07-18 12:41:52

数字化服务网格微服务

2020-10-10 10:37:54

微服务架构技术API

2023-11-01 08:08:22

k8s服务网格

2020-06-21 13:42:27

微服务服务网格服务网格工具
点赞
收藏

51CTO技术栈公众号