【译】别用大炮打蚊子—ServiceMesh 的替代方案
译者序
最近看到一篇文章,笔者深以为然:
复杂度只能有限消失和转移,不可能完全(甚至是大部分)消失,所以我们做软件架构往往追求的是 转移,用 专人专事 来应对复杂度,以提升效率
在做技术选型的时候,简单性 (控制复杂度)也是我们的一个重要考量,不能因为要解决一个问题而引入了更多问题
正文
服务网格是一项热门技术,有时甚至被吹捧为微服务成功的必要条件。然而,像许多抽象一样,服务网格可以节省实施时间,但不能节省学习时间。事实上,许多小平台团队都因为服务网格所增加的复杂性而感到不堪重负,尤其是在部署完成后的运维工作中。
自然地,人们会问:额外的复杂性是否真的超过了收益?
在这篇文章中,我们提出了一些在采用服务网格之前值得考虑的替代方案。
服务网格最受欢迎的优势有:
认证;
Ingress 加密;
集群内网络加密;
通信隔离。
对于每一个优势,我们都将展示相应的替代方案。在我们的经验中,这些方案更接近系统管理员已经熟悉的方案。对于缺乏专业知识或平台工程的团队来说,这些方案可能更具吸引力。
在某些情况下,你会需要服务网格,例如,当你需要让多个 kubernetes 集群之间的 Pod 到 Pod 的通信更加安全稳固之时。通过排除不满足你需求的解决方案,你将进一步说服自己为什么一开始会选择服务网格。
优势 1:使用 OAuth2 代理进行认证
许多应用团队需要在其微服务前面添加一个认证层。举个例子,完全实现 OAuth2 或 OpenID 涉及许多复杂的工作,应用团队更希望“某些组件”直接向其应用程序提供具有正确声明的 JWT token,以便他们能专注于应用特定的访问控制,而不是编写许多通用的、非业务差异化的样板代码。
我们以前在博客中介绍了如何将 Istio 与 OAuth2 代理集成来达到这个目的。但是,如果这是你想通过 Istio 实现的唯一目的,那么采用它则有点过犹不及。
替代方案:Nginx Ingress Controller
这是一个我认为更简单的解决方案,特别是对已经习惯于 Nginx 的团队来说。如果你仅仅需要传统的 oauth2 代理,Nginx Ingress Controller 已经能够和它进行集成了。你只需使用 auth-url 注解,Controller 会完成其余的工作。下图说明了此方案的原理:
我认为这个解决方案更简单的原因是,它实际上只影响流量如何进入你的 Kubernetes 集群。Pod 到 Pod 的通信工作方式与以前相同。
作为额外的好处,如果你熟悉 Nginx 但是担心 Ingress Controller 带来的自动化(译注:你担心配置文件不可控),你可以直接检查 Nginx 是如何配置的,输入下方命令即可:
默认情况下,你的应用程序不能获得 JWT token。要确保你的应用程序获取细粒度的访问控制所需的声明,你必须做到两点:• 给 Oauth2 代理添加 --set-authorization-header
命令行选项:这可以确保 Oauth2 代理生成 HTTP 认证 header。• 给你的 Ingress 添加以下注解: nginx.ingress.kubernetes.io/auth-response-headers: “authorization”
。这确保了 Nginx Ingress Controller 会将 Oauth2 代理添加的 HTTP A 认证 header 转发到你的应用程序。
更多细节和开箱即用的代码片段:
https://github.com/elastisys/compliantkubernetes/blob/main/user-demo/deploy/oauth2-proxy.yaml
https://elastisys.io/compliantkubernetes/user-guide/network-model/#ingress
优势 2:Ingress 加密
许多法规要求对不可信网络上的网络流量进行加密。例如,PCI-DSS 条例 4 规定:“通过加密将持卡人数据传输到开放的公共网络中。” GDPR 和瑞典医疗保健法包含类似的规定。
解决方案很简单:添加 TLS 终结。但是,TLS 终结并不具备业务差异性和应用相关性。理想情况下,平台应该“自动实现它”。我经常看到团队仅为此一项功能而采用服务网格,但实际上有一个更简单的替代方案。
替代方案:证书管理器
你可以安装 cert-manager,创建 ClusterIssuer,并通过注解将你的 Ingress 与该 ClusterIssuer 关联。证书管理器会和 LetsEncrypt 沟通并提供 TLS 证书,并在证书过期前轮转。
上图对此进行了说明,以及开箱即用的代码片段[https://elastisys.io/compliantkubernetes/user-guide/network-model/#ingress]。请参阅 cert-manager.io/cluster-issuer 注解。
优势 3:集群内网络加密
准备好面对一些争议。
我经常看见企业采用服务网格,仅仅是因为“mTLS 和 Pod 到 Pod 的加密很酷,并且由某些法规要求”。下面是我对这个话题的看法。
首先,你很少(如果有的话)需要 Pod 到 Pod 的加密。如上所述,PCI-DSS 和瑞典医疗保健法只要求在开放(即不可信)网络上加密。我经常听说团队采用 Pod 到 Pod 加密来“以防万一”底层网络不可信。如果你无法信任你的基础设施提供商,请更换提供商。因为再多的加密都无法阻止他们窃取你内存中未加密的数据。
其次,假设你真的需要集群内加密。例如,你想要在 2 个通过不可信网络连接的数据中心中搭建 Kubernetes 集群。或者,你想避免与两个数据中心之间的网络提供商签订另一份类似 GDPR 的数据保护协议(DPA)。
替代方案:CNI 级别加密
在这种情况下,只需在你的容器网络接口(CNI)提供商中启用 WireGuard 和/或 IPsec。这可以实现节点(node 而非 pod)到节点的网络流量加密的效果。至少 Calico 和 Flannel 支持此功能。例如,如果你使用 Kubespray 来配置 Calico,配置方式非常简单:
calico_wireguard_enabled: true
优势 4:网络通信隔离
服务网格带来另一个功能:它为每个 Pod 提供一个身份(identity),然后通过相互认证(mTLS)来实现基于身份的访问控制。这带来了两个好处:
首先,你的 Pod “不与陌生人交谈”,这可以让某些漏洞更难利用,如臭名昭著的 Log4Shell
其次,它减小了爆炸半径:如果一个 Pod 被攻破,攻击者会发现横向移动更加困难(译注:也就是很难从一个 pod 攻破另一个 pod)。
替代方案:网络策略
然而,使用网络策略可以以更简单和更标准化的方式达到相同的目的。它们就像容器化世界中的防火墙规则或安全组。本质上,随着 Pod 在每次部署后更改 IP 地址,网络策略将 Pod 标识转换为基于 IP 的防火墙规则,由 Linux 内核强制执行。
一个网络策略由两部分组成:selector 和 rules。selector 选择网络策略应用于哪些 Pod,可以匹配 Pod 标签或命名空间标签。rules 指定哪些到/从所选 Pod 的入口和出口流量是被允许的。Safeguards 可以用来确保每个 Pod 都能被某个网络策略选择到。
在一些组织中,网络安全性和应用安全性是不同团队的责任。这可以通过网络策略和 Kubernetes RBAC 来完成技术上的实现。只有网络团队被授权编辑网络策略,而应用团队只被授权在给定的命名空间中部署。
最后的建议:将命名空间视为“内部 API”。由于命名空间最终成为集群 DNS 名称的一部分,所以最好根据它提供的服务(例如“auth”、“database”、“licensing”)而不是团队名称(“team-green”、“team-yellow”等)来给命名空间取名字。这种做法也简化了网络安全团队设置网络策略的过程。
结论
简单性和可理解性是安全性的关键。尽管服务网格带来很大的好处,但在采用它们之前应考虑更简单的替代方案。我的经验是,网络和网络安全本身已经足够复杂。添加额外的一层会带来一定的风险:让你的平台团队不堪重负,还会给他们带来 on-call 的焦虑。
当然,有许多服务网格功能目前还没有更简单的替代方案,例如跨集群的安全通信,联邦网络的可观察性。如果你确实需要更高级的功能,我们希望本文能够帮助你作出明智的决定和拥抱新增的技术。
Kubernetes 网络和服务网格都在快速发展。就在最近几个月,Calico 增加了一个 eBPF 数据平面,Istio 被捐赠给CNCF。这样的事件可以很快推动采用或不采用服务网格的决策。我们当然会观察最新情况,并继续书写关于 Kubernetes 网络的文章。
原文
Alternatives to Consider Before Investing in Service Meshes :https://elastisys.com/dont-use-a-canon-to-shoot-a-mosquito-alternatives-to-consider-before-investing-in-service-meshes/
译者
版权声明: 本文为 InfoQ 作者【九零后程序员】的原创文章。
原文链接:【http://xie.infoq.cn/article/7cc42aba2b17a4448831101a6】。
本文遵守【CC-BY 4.0】协议,转载请保留原文出处及本版权声明。
评论