#Connectors Permission Model

连接器将发现集成对象的权限与使用这些集成访问目标工具的权限分开管理。

从用户角度来看，权限模型包含三个层次：

• 我能发现这个连接器吗？
• 我能通过平台浏览目标工具的数据吗？
• 我的工作负载能实际使用这个连接器访问目标工具吗？

这些层次是有意分开控制的。这样既能让平台保持连接器发现的便利性，又能保护工作负载中对真实工具的使用安全。

#Overview

连接器权限模型可以通过以下三个问题来理解：

这些问题是有意分开控制的。用户可能被允许发现连接器，但仍被阻止浏览工具数据或在工作负载中使用它。

#User Capabilities

#发现连接器类型和实例

ConnectorClass 定义了工具类型及其能力。Connector 表示一个具体的集成实例。

对用户来说，通常意味着：

• 如果他们可以读取 ConnectorClass，则可以发现集群中有哪些连接器类型。
• 如果他们可以读取 Connector，则可以发现某个具体集成存在，并在平台工作流中选择它。
• 如果他们可以管理 Connector 或 ConnectorClass，则可以更改集成行为，因此这些权限通常仅限管理员。

连接器的可见性还受范围影响。命名空间范围的连接器仅在其命名空间内可用，而项目范围和集群范围的连接器则更广泛共享。有关范围的更多信息，请参见连接器资源级别和权限。

#通过 Connectors API 浏览工具数据

Connectors API 通常是平台 UI 用来读取目标工具数据的路径。

常见示例包括：

• 克隆前列出 Git 分支
• 选择制品版本前列出镜像标签
• 列出项目、仓库或类似的选择器数据

当 enable-connector-apis-permissions 被禁用时，拥有对 Connector 的读取权限即可调用 Connectors API。

当 enable-connector-apis-permissions 被启用时，平台通过对目标连接器执行额外的 connectors/apis 权限检查，将连接器发现和 Connectors API 使用分开管理。

实际情况是：

• 能看到一个 Connector 并不总是足够的。
• 如果其角色不允许该连接器的 Connectors API 使用，用户仍可能无法浏览分支、标签或仓库。
• 在 Alauda Container Platform (ACP) 中，内置面向用户的角色通常已包含常见 UI 场景所需的面向读取的 Connectors API 权限。

此设计使平台支持便捷的只读发现，同时不会自动授予对工具的更广泛运行时访问权限。

有关请求流程本身的更多信息，请参见连接器 API。

#通过 Connectors Proxy 在工作负载中使用连接器

Connectors Proxy 通常用于工作负载或 CLI 需要使用连接器存储的凭据实际访问目标工具的场景。

常见示例包括：

• 通过代理端点进行 Git 克隆
• 通过 OCI 或 Harbor 代理拉取或推送制品
• 让工作负载使用 CSI 驱动渲染的配置

当 enable-connector-proxy-permissions 被禁用时，拥有对 Connector 的读取权限即可使用 Connectors Proxy。

当 enable-connector-proxy-permissions 被启用时，平台通过对目标连接器执行额外的 connectors/proxy 权限检查，将连接器发现和代理使用分开管理。

实际情况是：

• 能看到生产连接器仍然不够。
• 工作负载可能仍无法克隆、拉取、推送或访问受保护系统，除非被授予使用 Connectors Proxy 的权限。
• 该权限通常比 Connectors API 更加谨慎对待，因为它代表对目标工具的真实使用。

有关代理行为的更多信息，请参见Connectors Proxy 和 Connectors CSI Driver。

#Connectors Approval 的作用

Connectors Approval 不是权限模型本身，而是构建在 Connectors Proxy 之上的额外控制层。

当同时启用 enable-connectors-approval 和 enable-connector-proxy-permissions 时：

• 平台可以要求在允许工作负载使用受保护连接器之前进行审批。
• AccessPolicy 定义哪些连接器使用基于审批的控制。
• AccessRequest 记录工作负载对连接器的具体请求。

从用户角度看，Connectors Approval 主要影响工作负载是否可以实际使用连接器完成克隆、拉取、推送或部署等操作。它不替代 ConnectorClass 和 Connector 的基本可见性和管理权限。

如果您已经理解上述三层权限并想了解审批相关流程，请继续阅读Connectors Approval & Permission Gating。有关 API 详情，请参见AccessPolicy 和 AccessRequest。

#示例：同一个连接器，不同用户体验

以一个项目范围的生产 Harbor 连接器为例：

• 开发人员可能能在 UI 中看到该连接器。
• 同一开发人员也可能能通过 Connectors API 列出镜像标签，因为 Alauda Container Platform (ACP) 通常为选择场景授予面向读取的 API 权限。
• 但构建工作负载可能仍无法通过 Connectors Proxy 推送镜像。
• 如果该连接器需要审批，工作负载必须通过相应检查后才能获得代理使用权限。

这就是权限模型的核心思想：发现、浏览和实际运行时使用相关，但它们不是相同的权限。

#高级：平台如何映射这些能力

上述面向用户的能力通过 Kubernetes RBAC 实现。

#资源权限

资源权限控制用户是否能发现或管理集成对象：

• connectorclasses
• connectors

这些权限决定用户是否能看到连接器类型和连接器实例。

#能力权限

能力权限控制用户是否能通过特定的 Connectors 组件使用这些集成对象：

• connectors/apis 映射到 Connectors API
• connectors/proxy 映射到 Connectors Proxy

这些能力权限仅在对应功能标志启用时强制执行。

• 如果功能标志禁用，拥有对 Connector 的读取权限仍足以使用 Connectors API 或 Connectors Proxy。
• 如果功能标志启用，平台会执行上述额外的 connectors/apis 或 connectors/proxy 权限检查。

这就是为什么用户可能对 Connector 有读取权限，但在平台尝试浏览工具数据或工作负载尝试运行时使用连接器时仍被阻止的原因。

#Alauda Container Platform (ACP) 内置角色

Alauda Container Platform (ACP) 提供来自两个方面的内置角色：

• connectors-operator 提供 ConnectorClass 和 Connector 访问的基础角色。
• 连接器扩展为常见操作（如列出分支、标签、项目或仓库）提供额外的只读 Connectors API 权限。

实际上，这意味着 Alauda Container Platform (ACP) 通常能开箱即用支持常见的只读 UI 场景，同时仍将 Connectors Proxy 使用视为更敏感的能力。

#总结

连接器权限模型将三种用户能力分开管理：

• 发现连接器类型和连接器实例
• 通过 Connectors API 浏览工具数据
• 通过 Connectors Proxy 在真实工作负载中使用连接器

这种分离使平台能够保持日常 UI 场景的简洁，同时保护对敏感外部系统的运行时访问。

#下一步

• Connectors Approval & Permission Gating
• AccessPolicy
• AccessRequest
• Connector Resource Levels and Permissions
• Connectors API
• Connectors Proxy
• Feature Flags
• Architecture