#Connectors 审批与权限门控

#概览

Connectors Approval & Permission Gating 用于保护工作负载实际使用 Connector 的时刻，尤其是在访问经过 Connectors Proxy 时。它在标准的 Connector 权限模型之上，增加了基于策略的检查和临时权限授予。

当某个团队可以发现一个 Connector，但像提升到生产 Registry 这样的敏感操作必须等待审批时，这项能力就非常有用。

该功能依赖 enable-connectors-approval 和 enable-connector-proxy-permissions 两个开关。有关开关详情，请参见 Feature Flags。

如果这两个特性开关没有同时启用，则不会激活与审批相关的流程。

• 如果 enable-connector-proxy-permissions 被禁用，系统不会应用 proxy 能力权限层，因此审批无法对 proxy 使用进行门控。
• 如果 enable-connectors-approval 被禁用，系统不会创建或评估与审批相关的运行时流程。

在这种情况下，工作负载使用的是标准 Connector 访问模型，而不是经过审批门控的 proxy 访问。

#在权限模型中的位置

此功能不会替代 Connector Resource Levels and Permissions 中描述的标准 Connector 可见性和作用域规则，而是在运行时使用周围增加了一个额外的门禁。

在实践中，这意味着以下两件事可以同时成立：

• 用户可以读取一个 Connector，或者通过 Connectors API 使用标准权限模型已经允许的有限 API
• 同一个工作负载在通过 Connectors Proxy 使用该 Connector 时，仍然可能在审批检查通过之前被阻止

这种分离在“可以浏览或选择某个 Connector，但应更严格地控制其背后的真实操作”时非常有用。

#两个核心资源

AccessPolicy 回答的是：“这里应该应用什么审批和权限规则？”

AccessRequest 回答的是：“这个工作负载现在能使用这个 Connector 吗？”

这种分离是有意设计的：

• 如果你想了解整体能力和端到端流程，请留在本文
• 如果你需要设计长期规则，请继续阅读 AccessPolicy
• 如果你需要检查某次运行时请求或排查状态，请继续阅读 AccessRequest

#理解访问模型

在这项能力中，管理员在 AccessPolicy 中定义访问模型，系统通过 AccessRequest 对每次运行时使用进行评估。

从高层来看，工作负载通过 Connectors Proxy 使用 Connector 通常有两种常见方式：

• defaultPermission：匹配到的工作负载可以立即使用该 Connector
• checkGrantedPermission：匹配到的工作负载只有在所需检查通过后才能使用该 Connector

这意味着，同一个 Connector 能力可以根据风险等级以不同方式使用：

• 对于共享内部工具，管理员可以授予 defaultPermission，这样已批准的 namespace 或 ServiceAccounts 可以直接使用
• 对于生产 Registry 或生产集群，管理员可以要求在工作负载被允许使用 Connector 之前先完成检查

在运行时，工作负载通常会通过 Connectors CSI Driver 挂载 Connector 配置，然后调用该 Connector 的 proxy 端点来访问目标工具。如果匹配到的策略要求审批，系统会让工作负载保持等待状态，直到检查通过，然后为该工作负载授予临时 proxy 权限。如果检查被拒绝，CSI Driver 只会挂载一个 .error.json 文件（不会挂载任何配置文件），Pod 会在没有可用 Connector 配置的情况下启动，从而导致工作负载尽快失败。

#实际被门控的内容

此功能的设计目标是对 Connectors Proxy 的使用进行门控，而不是限制读取 Connector 对象本身。

这种区别很重要，因为 proxy 访问通常正是系统注入工具凭证或允许对目标系统执行敏感操作的地方。

典型示例包括：

• 将工作负载部署到受保护的 k8s 集群
• 将制品提升到生产 Registry
• 运行某个工作负载，但只有在检查通过后才能使用共享 Connector

授予的权限会限定在特定的工作负载上下文中，与广泛且长期存在的访问相比，这样可以降低 credential 复用风险。

#策略与请求的关系

AccessPolicy 是可复用的。一个策略可以应用于一个 Connector、一组 Connector，或者某个 namespace 中的所有 Connector。

AccessRequest 则是与运行时相关的。它绑定到一个目标 Connector、一个请求主体和一个上下文对象。该请求会记录哪些策略被匹配，以及所需检查是否已经通过，这样系统就可以决定是否为该工作负载同步门控后的权限。

二者共同将长期访问设计与短生命周期运行时授权分离开来：

• 使用 AccessPolicy 定义审批和权限模型
• 使用 AccessRequest 评估某一次真实的 Connector 使用

#Tekton Pipeline 示例

一个常见场景是 Tekton pipeline 通过名为 prod-harbor 的 Connector，将制品提升到生产 Harbor registry。

要使用这种模式，用户需要按如下方式准备 pipeline：

• 管理员为敏感 Connector（例如 prod-harbor）定义一个 AccessPolicy
• pipeline 定义中在提升任务之前包含一个 ApprovalTask
• 提升任务通过 CSI 挂载 Connector，然后使用受保护的 proxy 路径访问目标工具

这里，受保护的 proxy 路径指的是工作负载通过 Connector 访问目标工具时所使用的 Connectors Proxy 访问路径。

之后，系统会自动处理与审批相关的访问流程：

• 系统为运行提升任务的 Pod 创建一个 AccessRequest
• 默认情况下，AccessRequest 会在同一个 PipelineRun 中查找 ApprovalTask
• 如果该 ApprovalTask 已获批准，系统会授予临时 proxy 权限，提升任务继续执行
• 如果该 ApprovalTask 被拒绝，CSI Driver 会用 .error.json 文件代替配置文件进行挂载，而工作负载因为无法访问 Connector 而失败
• 如果该 ApprovalTask 仍处于 pending 状态，工作负载会一直等待，直到做出审批决定

这种模式让团队可以在平台中保留 Connector 的可用性，同时仍然要求在执行敏感的提升操作之前进行明确的审批步骤。

该模式下的一个典型 AccessPolicy 如下所示：

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: prod-harbor-approval
  namespace: devops
spec:
  connector:
    names:
      - prod-harbor
  checkGrantedPermission:
    spec:
      checks:
        - name: manual-approval
          ref:
            configMap:
              name: connectors-approvals-in-pipeline
      roleTemplate:
        ref:
          configMap:
            name: connectors-use-connectors-proxy-in-pod

在这个示例中，该策略面向一个敏感 Connector，并且只会在当前 pipeline 的 ApprovalTask 获批后，才向 Pod 授予 proxy 访问权限。

这两个引用的 ConfigMap 是 Connectors 组件提供的内置模板：

• connectors-approvals-in-pipeline 定义了默认的检查规则，用于匹配同一个 PipelineRun 中的 ApprovalTask
• connectors-use-connectors-proxy-in-pod 定义了审批通过后授予 Pod 的临时 proxy 权限

#典型使用场景

• 需要等待人工审批的生产制品提升
• 只有在审批通过后才能部署到生产集群
• 必须控制 proxy 访问的受保护环境部署
• 只有在审批通过后，特定工作负载运行才可使用的共享 Connector

#下一步

• AccessPolicy
• AccessRequest