我过去使用或研究过的身份和访问管理平台总是有很多不足之处。大多数时候,他们的审计跟踪不够强大。每个用户或每个会话的定价太贵。他们不容易在多个地区进行部署。而且,它们也不太容易在云端操作或扩展。
显然,现代IAM平台在市场上是一个空白。我需要这样一个平台,以便正确地完成我以前作为电子政务和IAM主管的工作(在瑞士)。但这样的平台并不存在。这时,我们开始思考并建立了今天的ZITADEL平台。直接跳到架构。
什么是ZITADEL?
ZITADEL是一个现代的云原生IAM平台,开发人员使用它来整合他们的认证和授权需求,而不需要运行他们自己的代码。ZITADEL有不同的用例和不同的消费模式,我们有几个差异化因素,如更强的审计跟踪和易用性,但在这篇博客中,我想重点介绍我们如何建立一个可扩展的、云原生的IAM平台,可以跨地区和跨云扩展。
为什么我们依赖CockroachDB
我们早在2019年就开始了构建ZITADEL的旅程,当时最大的一个问题是:哪种数据库可以满足我们所有的需求!?由于我们假设要建立一个ES系统(Event Sourced),主要是为了在架构中嵌入一个伟大的审计跟踪,我们得出的结论是也要使用CQRS(命令查询责任隔离)。因此,我们需要评估哪个数据库可以处理这两种设计模式,同时还能满足我们的要求,如下所述。
IAM数据库的要求。
-
事件库的强一致性
-
为我们的查询数据库提供强大的可用性保障
-
云原生设计
- 能够在Kubernetes上运行,开箱即用
- 横向可扩展性是必须的
- 能够跨越多个数据中心和地区运行
- 易于实现自动化
经过初步评估,我们选择了CockroachDB,因为它符合我们所有的要求。最重要的一点是,CockroachDB可以在横向扩展的同时保持强大的一致性。此外,将我们的查询端数据库存储在同一个集群中是一个很大的优点--从操作的角度来看,不需要为每个作业提供服务,这很方便。那只会使操作变得棘手,而且它使我们的开发人员能够专注于一个经过战斗考验的存储,而不需要总是重新考虑在哪里存储数据。
我们如何运行ZITADEL和CockroachDB
在CAOS,ZITADEL的创建者,我们坚定地致力于GitOps。我们在过去 曾用德语写过一篇博客并谈到了这一点。对我们来说,这意味着每个ZITADEL的部署都有自己的Git仓库,所有需要的配置和秘密(是的,它们是加密的)都存储在那里。为了帮助我们实现生命周期的自动化,我们创建了我们的项目ORBOS。
通过ORBOS,我们能够在20分钟内从头开始声明和运行超融合的ZITADEL集群。正如你在下面的图形中看到的,ORBOS由两个操作者组成。ORBITER负责包括Kubernetes在内的基础设施组件的生命周期,BOOM负责管理这些工具。
为了部署和循环ZITADEL和CockroachDB,我们创建了一个ZITADEL运营商,它包含了所有必要的操作逻辑来自动运行ZITADEL。这个操作者为新的ZITADEL版本进行模式迁移,或者备份和恢复CockroachDB,管理必要的客户端证书以连接到CockroachDB,诸如此类。
我们对这种设置相当满意,因为它允许我们在任何地方管理和运行系统。有了GitOps,我们对系统的变化也有了很好的审计跟踪。
目前我们在GCP和Cloudscale上并行运行ZITADEL,这两个供应商的数据中心都在瑞士。
有趣的副标题。ORBOS作为一个Kubernetes平台被我们合作的很多公司单独使用。它甚至为一个政府供应商的SaaS基础设施提供动力。
连接多个云的挑战
到今天为止,我们面临的主要挑战之一仍然是多个数据中心之间的连接。如果你只依赖一个云供应商,这对你来说并不是一个问题。然而,我们很早就决定要在多个供应商之间运行我们的云计算产品zitadel.ch,以减少一个供应商所带来的任何负面影响--无论是从操作的角度,如中断或从风险的角度。由于我们要处理来自客户的敏感数据,我们希望减少过于依赖单一供应商的风险。
今天,我们通过利用良好的老式IPSec VPN作为传输手段来连接不同的供应商。对于Kubernetes的连接,我们通过VPN与BGP对等和IPIP连接每个集群。然而,这并不能很好地扩展,而且往往会有相当多的管理开销。
为了连接每个集群中的Cockroach数据库,我们依靠CockroachDBGotchas & Solutions的这篇非常有用的博客 在Kubernetes集群中运行分布式系统,因为我们选择使用DNS Chaining方法。但由于我们拥有完整的路由功能,这要归功于Project Calico,我们能够通过覆盖层直接将流量发送到每个集群的DNS。
为了解决VPN开销的问题,我们目前正在测试Cloudflare的Magic WAN产品,作为一种手段将我们的数据中心连接到具有冗余GRE/IPSec连接的虚拟WAN。这意味着我们不需要为东西向的连接建立和维护一个网状结构。CockroachDB和Magic WAN的组合看起来是一个非常强大的架构。
如果你不希望自己承担管理的负担,我们可以推荐CockroachCloud。一个真正的云数据库!
身份和访问管理的未来
我们认为CockroachDB非常适合支持我们继续建立最具创新性的身份和访问管理平台的计划。我们认为未来的两个主要功能是changefeeds和geo-partitioning。
Changefeeds可以加快后端程序的处理速度,这些程序会产生我们的查询数据库,也会产生分析性的东西。我们目前正在考虑通过机器学习来运行我们的事件,以学习模式来更好地缓解攻击。
通过地理分区,我们的目标是让我们的客户有能力决定在哪个地区存储他们的数据。例如,今天我们的系统只在瑞士运行,但当我们扩展到欧盟时,我们希望让我们的客户可以选择说他们的数据存储在哪个地区。
如果你有兴趣了解更多关于ZITADEL的信息,请前往阅读《CAOS和ZITADEL架构 介绍》。还有一个关于我们使用CockroachDB的详细案例研究。
对于那些对代码感兴趣的人,请访问caos/zitadel: ZITADEL - Cloud Native Identity and Access Management或caos/orbos:ORBOS - GitOps的一切