大家好！这里是陪伴大家MSA之旅的博客。今天，我们将深入探讨在Kubernetes环境中运行微服务时可能遇到过的“信任”问题。
在无数服务混乱漂浮的集群中，服务A如何信任服务B并与之通信呢？这就像电影里的间谍一样，需要互相验证身份。🕵️♀️
Istio是如何解决这个复杂的身份验证问题的呢？秘密的钥匙就在于SPIFFE。
🤔 传统方式的问题：“IP地址，不可信！”
过去，我们基于服务器的IP地址设置防火墙规则并相互识别。例如：“来自10.0.1.10的请求应该是‘支付服务’。允许它！”就是这样的方式。
但在容器和Kubernetes时代，这种方式不再适用。
- 动态IP地址 🌊： Pod随时可能死亡并重新启动。每次重启，IP地址都会改变。IP地址不再能作为固定的身份。
- 安全漏洞 🔓： 部署在同一节点(Node)上的Pod们如何相互信任呢？仅凭IP地址，很难区分是真正的“支付服务”还是冒充“支付服务”的恶意Pod。
最终，我们必须关注的不是“来自哪里(where)”，而是“是谁(who)”。这正是工作负载身份(Workload Identity)概念出现的时刻。
✨ 救星登场：面向所有人的安全生产身份框架，SPIFFE
SPIFFE (Secure Production Identity Framework for Everyone)顾名思义，是一个为所有工作负载提供安全、标准化身份的“框架”和“标准规范”。它不是一个特定的软件，而是一个约定，即“工作负载的身份证必须是这种格式，并且必须以这种方式颁发和验证”。📜
Istio采纳了SPIFFE标准，为服务网格中的所有工作负载分配唯一的身份。
SPIFFE的核心组成部分 ✌️
- SPIFFE ID: 工作负载的唯一身份证号码。它以URI形式表示，结构如下：
- trust-domain: 信任域，即安全边界。通常指一个Kubernetes集群。(例如: cluster.local)
- workload-identifier: 在该域内唯一标识工作负载的路径。(例如: /ns/default/sa/my-app-sa)两者结合起来就是这个样子。现在，这个ID将指向全球任何地方，使用cluster.local集群中default命名空间下的my-app-sa服务账户的工作负载。
- spiffe://cluster.local/ns/default/sa/my-app-sa
- spiffe:///
/
- SVID (SPIFFE Verifiable Identity Document): 证明SPIFFE ID的“实体身份证”。这份文档中包含工作负载的SPIFFE ID和过期时间等信息，经过加密和签名。如果有人问“你的SPIFFE ID是spiffe://…对吗？”，你就可以出示SVID来证明。📄
- SVID可以以两种形式颁发。
- X.509-SVID: 我们熟悉的SSL/TLS证书形式。主要用于服务间的mTLS(相互TLS)通信。
- JWT-SVID: JWT(JSON Web Token)令牌形式。可用于应用程序级别的用户认证等。
⚙️ Istio如何实现SPIFFE？(一窥整体流程)
那么，Istio是如何实际实现SPIFFE标准并为工作负载颁发身份证(SVID)的呢？
- Pod创建 & Sidecar注入 🚀： 当一个新的Pod创建时，Istio的Sidecar代理(Envoy)会随之注入。
- 身份证明请求 🙋： Sidecar代理向Istio的控制平面istiod请求“给我颁发一个身份证！”。此时，它会附带Kubernetes服务账户(Service Account)令牌等信息来证明自己的身份。
- 身份验证及SVID颁发 🧐： istiod充当CA(Certificate Authority)的角色。它验证请求代理的服务账户令牌，并基于此生成SPIFFE ID。(例如: spiffe://cluster.local/ns/prod/sa/payment-service)
- SVID传递及mTLS通信 🤝： istiod将包含生成的SPIFFE ID的X.509-SVID(证书)传递给Sidecar代理。现在，这个代理就拥有了自己的“身份证”。当与其他服务通信时，它们会相互交换这些SVID来验证身份，并建立安全的mTLS通信通道。
所有这些过程都无需开发人员介入，自动完成。这就是服务网格的强大之处！💪
❌ 其他方法为何不是正确答案？
除了SPIFFE，我们也可以考虑其他方法。但为什么Istio没有选择它们呢？
- 单纯使用JWT令牌 🔑：
- 为何不是？ JWT是一种优秀的认证方式，但其本身并非标准化的身份体系。如果没有统一的规范来定义包含哪些信息、由谁颁发以及如何验证，那么每个系统都会各自实现，导致兼容性和扩展性下降。SPIFFE将所有这些都定义为标准。
- 云提供商的IAM (Identity and Access Management) ☁️：
- 为何不是？ AWS IAM、Google Cloud IAM等都依赖于特定的云平台。在多云或混合云环境中，难以一致地管理工作负载身份。SPIFFE提供了一个平台中立的标准，使得在任何环境中都能以相同的方式管理身份。
- OAuth 2.0 🛡️：
- 为何不是？ OAuth 2.0主要侧重于委托用户的“权限”。它适用于“您是否允许此应用程序代表您访问Google相册？”之类的场景。它与证明工作负载本身“是谁”的“身份(Identity)”问题焦点不同。
总而言之，SPIFFE是一个平台中立、专注于工作负载“身份”的强大且标准化的框架，因此它与Istio的理念完美契合。
现在，您的微服务不再通过不稳定的IP地址，而是通过SPIFFE这一不可伪造的身份证，相互信任并安全地进行通信。😊
发表回复