Image credit: Robert McGoldrick
今天我们非常高兴地宣布推出 Linkerd 2.3。这个版本将mTLS从实验阶段毕业到完全支持的功能，并新加了几个重要的安全功能。最重要的是，Linkerd 2.3 默认情况下会在网格服务之间进行经过身份验证的保密通信。
这是回答我们一年多前提出的挑战的第一步：比不安全的通信，我们能否为Kubernetes更简单地提供安全的通信？
这不仅仅是一个理论问题。在大多数Web浏览器和Web站点使用强大的加密和身份验证而不需要用户另花功夫的世界中，Kubernetes服务在没有身份验证和纯文本的情况下进行通信的情况越来越奇怪。为什么在Reddit上冲浪猫图片比我们自己的应用程序内部有更多的安全保障？
确保Kubernetes服务之间的通信是迈向采用零信任网络的重要一步。在零信任方法中，我们放弃关于数据中心安全边界的假设，而是将关于身份验证，授权和机密性的要求“降低”到单个单元。在Kubernetes术语中，这意味着在群集上运行的服务验证，授权和加密自己的通信。
但是给用户带来负担的安全性，是不能实际使用的安全性 - 特别是复杂的设置和配置。如果零信任是Kubernetes网络安全未来的基础，那么采用零信任的成本必须尽可能接近零。在Linkerd 2.3中，我们正面迎接这一挑战：
-
控制平面附带证书颁发机构（简称“identity”）。
-
数据平面代理从此身份服务接收TLS证书，该证书与代理所属的Kubernetes服务帐户绑定，每24小时轮换一次。
-
数据平面代理使用这些证书自动将网格服务之间的所有通信升级到经过身份验证的加密TLS连接。
-
由于控制平面也在数据平面上运行，因此控制平面组件之间的通信以相同的方式得到保护。
所有这些都是默认启用的，不需要配置。这意味着，从2.3版本开始，Linkerd现在为你提供所有网格服务之间的加密，经过身份验证的通信，而你无需付出任何努力。这可能不是Kubernetes中零信任网络所需要的全部，但这是一个重要的开端。
此版本代表了Linkerd安全路线图的重大进步。在即将发布的博客文章中，Linkerd创建者Oliver Gould将详细介绍这种方法的设计权衡，并介绍Linkerd即将出现的关于证书链，TLS实施，服务帐户以外身份和授权的路线图。我们还将于太平洋时间2019年4月24日星期三上午10点举行的Linkerd线上社区会议讨论这些主题（以及2.3中的所有其它有趣功能）。
https://www.meetup.com/Linkerd-Online-Community-Meetup/events/260356731/
准备好试试吗？通过我们的每周边缘版本跟踪2.x分支的那些人已经看到了这些功能的实际应用。无论哪种方式，你都可以通过运行下载稳定的2.3版本：
curl https://run.linkerd.io/install | sh
最后，如果我们没有指出这种方法深受我们在Smallstep，Cloudflare，Let's Encrypt，Mozilla以及其他致力于在互联网上保证安全的组织的朋友的深刻启发，我们将会失职。
Linkerd是一个社区项目，由CNCF托管。如果你有功能请求，问题或评论，我们很乐意让你加入我们快速成长的社区！
稿源：CNCF