#AccessRequest

#概述

AccessRequest 是一个命名空间范围的运行时记录，用于审批门控的代理访问 Connector。

它将以下内容绑定在一起：

• 请求访问的主体
• 目标 Connector
• 该访问所针对的运行时上下文对象

在 Connectors 审批模型中，AccessPolicy 定义规则，而 AccessRequest 跟踪一次实际的访问尝试。

在大多数情况下，用户不会手动创建 AccessRequest。当工作负载尝试通过 Connectors CSI Driver 使用 Connector，但尚未拥有所需的 connectors/proxy 权限时，会自动创建它。

#可用性

AccessRequest 是 Connectors 审批功能的一部分。

在使用此工作流前，请启用：

• enable-connectors-approval
• enable-connector-proxy-permissions

更多信息请参见 功能开关。

#理解 AccessRequest

#它代表什么

AccessRequest 记录一次具体的运行时请求，而非可复用的策略。

其关键字段包括：

• spec.subject：请求访问的主体。在审批门控的 CSI 场景中，通常是工作负载的 ServiceAccount。
• spec.connectorRef：请求的 Connector。引用的 Connector 总是在与 AccessRequest 相同的命名空间中。
• spec.context.objectRef：该请求绑定的运行时对象。目前仅支持 Pod。

该资源有意面向运行时：

• 它跟踪一个工作负载上下文的审批进度
• 仅在检查通过后授予临时权限
• 在该工作负载上下文结束后即失去意义

#它与 AccessPolicy 的关系

AccessPolicy 回答以下问题：

• 哪些 Connector 需要审批门控访问
• 必须通过哪些检查
• 审批后应授予哪些权限

AccessRequest 回答不同的问题：

• 对于特定主体、Connector 和 Pod 上下文，访问是否已被批准并同步

这是两者的主要边界：

• AccessPolicy 解释可复用规则
• AccessRequest 解释该规则的一次运行时评估

当 AccessRequest 首次匹配策略时，控制器会将匹配的 AccessPolicy.spec 条目快照存储到 status.policies 中。即使原始策略后来发生变化，也能保持请求的稳定性。

策略模式请参见 AccessPolicy API 参考。

#它如何被创建和处理

典型流程如下：

1. 工作负载尝试通过 Connectors Proxy 或 Connectors CSI Driver 使用 Connector。
2. 如果工作负载已拥有该 Connector 和 Pod 上下文所需的 connectors/proxy 权限，则无需 AccessRequest。
3. 如果缺少该权限，CSI 流程会创建或复用一个 AccessRequest。
4. 控制器验证 Pod 上下文，解析目标 Connector，并匹配带有 checkGrantedPermission 的 AccessPolicy 资源。
5. 控制器找到匹配的检查资源，如 ApprovalTask，并将其结果记录在 status.policies[].matchedChecks 中。
6. 所有匹配检查通过后，系统为请求主体创建临时的 Role 和 RoleBinding。
7. 当 Pod 完成、被删除或 Connector 不再有效时，临时权限被清理。

这意味着 AccessRequest 是审批状态与实际 RBAC 权限同步之间的运行时桥梁。

#示例

以下示例展示了一个请求的结构：

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessRequest
metadata:
  name: prod-harbor-build-pod-7x9k2
  namespace: connectors-shared
spec:
  subject:
    kind: ServiceAccount
    name: builder
    namespace: cicd
  connectorRef:
    name: prod-harbor
  context:
    objectRef:
      apiVersion: v1
      kind: Pod
      name: build-pod-7x9k2
      namespace: cicd

该示例展示了一个重要模式：

• AccessRequest 存储在 Connector 命名空间：connectors-shared
• 请求的 ServiceAccount 位于工作负载命名空间：cicd
• 请求绑定到一个 Pod，而非绑定到使用同一 ServiceAccount 的所有未来 Pod

#读取状态

AccessRequest.status 告诉您当前运行时审批流程被阻塞或完成的位置。

重要条件包括：

• ContextObjectValid：绑定的 Pod 是否仍存在且活跃
• ConnectorResolved：引用的 Connector 是否仍存在
• AccessPolicyMatched：是否有审批导向的 AccessPolicy 匹配此请求
• AccessCheckReady：匹配的检查是否通过、待定或被拒绝
• AccessPermissionSync：临时权限是否已同步、仍待定或已清理
• Ready：基于上述条件得出的整体结果

常见解释：

• 审批仍在等待：AccessCheckReady = Unknown，原因 Pending
• 访问已授予且可用：Ready = True 且 AccessPermissionSync = True，原因 Synced
• 访问被拒绝：AccessCheckReady = False，原因 Rejected
• 运行时结束后权限被清理：AccessPermissionSync = True，原因 PermissionCleanUp

#操作注意事项

• AccessRequest.spec 在创建后不可变更。如果主体、Connector 或上下文发生变化，系统会使用不同的请求。
• AccessRequest 通常仅存在于审批门控访问场景。如果没有匹配的审批策略，它不会成为可复用的权限记录。
• 生成的权限既限定于请求的 Connector，也限定于运行时 Pod 上下文，有助于执行最小权限原则。

#后续内容

• 重新回顾整体流程：Connectors 审批与权限门控
• 重新回顾策略设计：AccessPolicy
• 学习模式定义：AccessRequest API 参考
• 学习审批规则定义：AccessPolicy API 参考