使用 SpiceDB 过滤 Kubernetes API 的 ACL

ChaITSimpleLove

132人浏览 · 2025-12-02 11:40:52

ChaITSimpleLove · 2025-12-02 11:40:52 发布

AuthZed 被 KuppingerCole 评为 2025 年新星，截止目前 https://github.com/authzed/spicedb 有 6241 star.

地址：https://authzed.com/z/kuppingercole-rising-star-2025

在这里插入图片描述

今天，我们开源一个内部项目：SpiceDB KubeAPI Proxy

SpiceDB-KubeAPI-Proxy
通常，当我们宣布内部项目作为开源发布我们更希望已经对其生产质量充满信心。然而，由于社区成员对代理项目的广泛关注，我们决定在达到 1.0版本之前将其开源。

SpiceDB Operator is Open Source

SpiceDB KubeAPI Proxy 是什么？

SpiceDB KubeAPI Proxy 作为网络代理，位于 Kubernetes 客户端（如 kubectl 或 client-go）和 Kubernetes 集群之间。它向客户端展示为一个完整的 kube-apiserver。

收到请求后，代理利用 SpiceDB 决定如何将请求转发到上游的 kube-apiserver。通过查询 SpiceDB，代理决定请求是否可以继续，以及如何过滤来自 Kubernetes 的响应列表——包括通过请求进行的实时更新。

此外，代理还支持向 Kubernetes 传递写请求，在 SpiceDB 和 Kube API 之间执行分布式事务。这确保权限数据与后台集群保持同步。代理维护一个持久的作日志，并可配置为围绕双写执行乐观或悲观锁定。

k8s-for-spicedb

对于你想如何在 SpiceDB 中存储权限，或者如何利用这些数据授权请求，没有任何假设。相反，代理被配置为一套规则，决定如何授权请求和过滤响应：

检查规则：这些规则决定请求是否被授权继续。例如，规则可能规定用户只有在拥有 SpiceDB 权限的情况下才能在命名空间中列出 Pod。

foonamespace:foo#list@user:alice

过滤规则：用于根据 SpiceDB 数据过滤来自 kube-apiserver 的响应。例如，一条规则可能规定，只有当 SpiceDB 中存在对应关系枚举允许的播客时，用户才能在命名空间中看到这些播客，比如和。在这个例子中，只会看到 pod 和 在命名空间 中。过滤规则扩展到请求，并能动态过滤观察事件。

foopod:foo/a#view@user:alicepod:foo/b#view@user:alicealiceabfoowatch

写规则：用于根据代理授权的请求写入 SpiceDB 数据。例如，如果在命名空间中创建了一个新的 pod，一条规则可能会要求写入 SpiceDB 以授予所有权的关系，例如：双写过程对 SpiceDB、Kube API 和 Proxy 本身的失败具有韧性。

alicecfoopod:foo/a#view@user:alice

由于代理以 kube-apiserver 形式呈现，它可以配置为独立的用户认证，支持后台的 Kubernetes 集群。可以查看GitHub仓库，那里有更全面的文档和示例。

github 仓库，spicedb-kubeapi-proxy)

我们为什么要写它？

我们编写代理是为了支持管理 Authzed Cloud 的多租户版本控制平面（目前处于抢先体验阶段），并为 Authzed Dedicated 的控制平面提供细粒度权限。

Authzed Cloud，https://authzed.com/docs/authzed/guides/picking-a-product#cloud
Authzed Dedicated，https://authzed.com/docs/authzed/guides/picking-a-product#dedicated

AuthZed 所有面向用户的基础设施都通过与一组内部 Kubernetes 控制器的交互来运行。代理是网页仪表盘与后台控制平面之间的中介，确保用户只能访问他们被授权查看的资源。

在实现代理之前，所有授权专用仪表盘的用户都拥有对其控制平面的完全权限。利用 SpiceDB 为控制平面提供细粒度权限，使我们能够为客户推荐“狗粮”架构。这种方法使组织所有者能够对其专用控制平面进行细致控制。此功能将在未来几个月内向专属客户推送。

Kubernetes 授权层技术上是模块化的，因此这个项目本可以作为 授权插件 开发。然而，这种方法需要分支 Kubernetes，我们觉得过于繁琐。我们的目标是在生产环境中验证这些概念，然后再提出与 Kubernetes 更深入集成的方法。这可能涉及倡导更具插拔性的权威结构（类似 CNI 或 CRI）。

k8s-access-authn-authz 授权模块

特别感谢 Lucas Käldström ——他关于 Kubernetes 中 ReBAC 的见解和讨论，激发了我们开源代理的决定。

我应该用它吗？

现在正是跳入、实验和反馈的最佳时机，因为 API 和实现还在向 1.0 版本的演进中。话虽如此，这可能还不是你在生产阶段应该依赖的东西。我们计划在几个月内发布 1.0 版本，前提是社区反馈充分并进行了实际测试。

接下来是什么？

未来，我们可能会探索用于运行时定义代理规则的 Kubernetes API，甚至考虑一个直接替代 RBAC 的 API，用于采用 ReBAC 模型的组件。目前，我们专注于完善生产应用的解决方案。

如果其他人也觉得这个解决方案和我们一样有用，我们可能会探索更无缝地集成到 Kubernetes 本身的方法，类似于网络、存储和容器运行时的实现。

此外，虽然看似遥远，但 Kubernetes 有可能运行在 CockroachDB 之上，这可能使我们能够在单一事务中更新 SpiceDB 和 Kubernetes。

总结

SpiceDB KubeAPI Proxy 是 Authzed 开源的一款网络代理工具，其核心功能是在 Kubernetes 客户端（如 kubectl or client-go）与集群之间插入权限控制层，通过 SpiceDB（一款开源的关系型访问控制引擎）实现细粒度的 API 访问授权与资源过滤。

关键信息如下：

一、工具核心功能

该代理作为 Kubernetes API 服务器的 “镜像”，通过三类规则实现权限管理：

Check Rules（检查规则）

判断请求是否被允许执行。例如：用户 alice 仅能在命名空间 foo 中执行 list pods 操作，需满足 SpiceDB 中存在 namespace:foo#list@user:alice 的权限关系。

Filter Rules（过滤规则）

根据 SpiceDB 数据过滤 Kubernetes API 的返回结果（包括 watch 实时更新）。例如：仅当 SpiceDB 中存在 pod:foo/a#view@user:alice 和 pod:foo/b#view@user:alice 时，alice 才能看到这两个 Pod。

Write Rules（写入规则）

在 Kubernetes 资源变更时同步更新 SpiceDB 权限。例如：alice 创建 Pod c 后，自动在 SpiceDB 中添加 pod:foo/c#owner@user:alice 的关系，确保权限与资源状态一致。

此外，代理支持分布式事务，确保 SpiceDB 与 Kubernetes 数据同步（如写入操作失败时的重试机制），并允许独立于集群的用户认证配置。

二、开发背景与动机

Authzed 开发该工具的核心原因是：

支撑其 多租户控制平面（Authzed Cloud 和 Dedicated 服务），确保不同用户仅能访问自己的资源。
避免直接修改 Kubernetes 源码（如 开发 Authz 插件需 fork 集群 ），通过代理模式实现 “非侵入式” 权限增强。
验证 ReBAC（基于关系的访问控制）在 Kubernetes 中的应用价值，未来可能推动 Kubernetes 原生支持更灵活的权限架构（类似 CNI/CRI 插件机制）。