【翻译】确保云原生通信的安全：从入口到服务网及更远的地方

作者：杰森-摩根2022年2月3日

特邀文章，原载于大使实验室博客，作者：Jason Morgan

作为开发者和运营商，我们都知道确保数据在传输和休息时的安全的重要性。然而，我们几乎没有一天不听说某个高知名度的公司出现了漏洞。这是为什么呢？其中一个原因是，确保数据安全往往是一个复杂的过程，要了解谁对什么负责并不容易。

在这篇博客中，我们将讨论与用户流量进入和在云原生应用程序中移动有关的安全管理挑战，并探讨入口和服务网在Kubernetes世界中的作用。

如果你想了解如何亲身体验这项技术，请参加我们于美国东部时间2月17日中午12点/欧洲中部时间2月17日下午6点举办的研讨会，即使用Emissary-ingress和Linkerd进行端到端加密的指南。

入口：前门和护照控制

实际上，所有的云原生应用都会向终端用户暴露功能，可能是通过网站、以开发者为中心的API或与后端API互动的移动应用。通常，这种流量应该被加密，以防止窃听者截获和了解相关的数据或信息。还有一种情况是，用户必须经过认证（authn）和授权（authz）才能对我们的应用程序提出请求。

在Kubernetes的世界里，所有这些用户产生的流量将通过一个入口进入我们的集群。这是处理流量加密的地方（终止或通过），也是发生用户级authn和authz的地方。一个入口控制器负责提供一个可公开寻址的负载平衡器，入口资源定义配置，如哪些路由需要传输级安全（TLS）和authn/authz。

服务网：内部走廊和安全检查点

当技术专家谈论端到端加密时，他们的意思不仅仅是从客户端到集群的前门。要做到真正的端到端，我们的微服务环境内部的网络流量也需要进行加密。这就是服务网格和mTLS发挥作用的地方。通过整合入口舱、我们的前门和构成我们应用程序的所有舱，我们能够在请求的整个生命周期内扩展加密。

像Linkerd这样的服务网可以使用mTLS来保护传输中的信息，并确保我们应用程序的各个组件只允许与 我们授权的特定服务对话。这种授权依赖于我们的mTLS身份，将每个服务限制在集群中预先批准的服务允许列表中。这种传输中的加密和政策的结合确保了集群中的所有通信都是私有的，并且是经过授权的。

想了解更多吗？请亲身体验一下CNCF的Emissary-ingress和Linkerd。

如果这听起来很有趣，请参加我们2月17日的实践研讨会：使用Emissary-ingress和Linkerd的端到端加密指南。在研讨会上，我们将分享获得入口TLS、集群内mTLS、高级L7路由、速率限制、嵌入式认证等方面的最佳实践。在对每个项目进行快速概述后，我们将展示这些项目如何相互补充，并成为你的Kubernetes堆栈的一个重要补充。今天就注册吧!