AccessPolicy

概述

AccessPolicy 是一个命名空间范围的资源，用于控制谁可以通过 Connectors Proxy 使用 Connectors。

它定义了三件事：

哪些 Connectors 受该策略覆盖
代理访问是默认授予还是仅在检查通过后授予
哪些主体受该访问模型覆盖

在 Connectors 审批模型中，AccessPolicy 是策略定义，而实际的运行时请求由 AccessRequest 单独跟踪。

INFO

请在阅读本文件前先阅读 Connectors Approval & Permission Gating。

本文档重点关注管理员设计的长期规则：

哪些 Connectors 受覆盖
谁应获得默认代理访问权限
在授予临时代理访问权限之前必须通过哪些检查

它不会重复单个工作负载的完整运行时生命周期。有关详细内容，请继续阅读 AccessRequest。

INFO

在此模型中，使用 connector 指的是通过 Connectors Proxy 使用 connector 的无密访问路径，无论是直接使用还是通过 Connectors CSI Driver。

AccessPolicy 不控制 Connectors API 访问。Connectors API 使用单独的 connectors/apis 权限，通常用于 UI 资源发现或其他基于 API 的集成。

可用性

AccessPolicy 是 Connectors Approval 功能的一部分。

使用前请启用：

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

更多信息请参见 Feature Flags。

理解 AccessPolicy

“使用 Connector” 的含义

AccessPolicy 关注的是代理访问，而非读取 Connector 对象或通过 Connectors API 浏览资源。

使用 connector 的典型示例包括：

工作负载向 Connector 的代理地址发送请求
Pod 通过 Connectors CSI Driver 挂载 Connector 配置，然后通过代理使用目标工具
流水线工作负载在审批后获得使用敏感 Connector 的临时权限

典型的 不属于 AccessPolicy 范围的示例包括：

读取 Connector 对象本身
通过 Connectors API 浏览分支、标签或其他面向 UI 的资源
授予平台用户 Connectors APIs 权限

AccessPolicy 的工作原理

AccessPolicy 位于 Connector 定义和运行时访问之间：

Connector：定义如何访问目标工具及如何认证
AccessPolicy：选择 Connectors 并定义谁可以通过这些 Connectors 提供的 Connectors Proxy 访问目标工具
AccessRequest：记录需要审批评估的单次运行时访问尝试
生成的 Role 和 RoleBinding：系统根据策略模板创建的具体 RBAC 对象

如果您需要了解这些部分如何协同工作，请参见 Connectors Approval & Permission Gating。本文档专注于策略设计和策略匹配。

总体流程如下：

工作负载尝试通过 Connectors Proxy 或 Connectors CSI Driver 使用 Connector。
系统评估匹配的 AccessPolicy。
如果策略使用 defaultPermission 且工作负载的 ServiceAccount 被覆盖，则允许访问。
如果策略使用 checkGrantedPermission，系统会在 AccessRequest 中跟踪运行时尝试，并仅在检查通过后授予配置的代理权限。

有关运行时请求的资源模式，请参见 AccessRequest API Reference。

两种访问模型

对于一个 Connector，AccessPolicy 通常使用以下两种代理访问模型之一：

使用 defaultPermission 授予默认代理访问：匹配的 ServiceAccounts 可立即通过 Connector 代理访问目标工具
使用 checkGrantedPermission 授予审批后访问：运行时请求必须通过检查后才授予代理权限

实际上，这意味着通过一个 Connector 的访问通常要么在已知范围内始终允许，要么对敏感使用进行审批控制。接下来的两节先介绍这两种模型，后面的常见配置模式章节展示如何将它们限定到特定 Connectors 和 ServiceAccounts。

授予默认代理访问

spec.defaultPermission 是策略中立即授予代理访问权限的部分，无需任何审批检查。

通常在以下情况下选择此方案：

Connector 在命名空间或项目内风险较低
一个范围内的所有工作负载都应直接通过 Connector 代理访问目标工具
需要稳定的非临时权限模型

大多数情况下，内置的 connectors-use-connectors-proxy 模板是合适的起点。它是核心 Connectors 组件安装的角色模板，授予匹配 Connector 的 connectors/proxy 权限。

当一个 Connector 应始终在命名空间、项目或集群范围内可用时，通常策略中只需包含此权限部分。

有关覆盖哪些 Connectors 和 ServiceAccounts 的配置，请参见常见配置模式。

示例

以下策略允许 devops 命名空间中的 builder 和 deployer 立即访问所有 OCI Connectors 的代理：

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: oci-default-access
  namespace: devops
spec:
  connector:
    matchLabels:
      connectors.alauda.io/connectorclass: oci
  defaultPermission:
    roleTemplate:
      ref:
        configMap:
          name: connectors-use-connectors-proxy
    bindingTemplate:
      serviceAccounts:
        - names:
            - builder
            - deployer
          namespaceSelector:
            names:
              - devops

审批后授予访问

spec.checkGrantedPermission 仅在所有配置的检查通过后授予代理权限。

通常在以下情况下选择此方案：

Connector 较为敏感
访问应仅针对单次运行时活动授予
审批是交付或推广工作流的一部分

最常见的内置组合是：

checks[].ref.configMap.name: connectors-approvals-in-pipeline
roleTemplate.ref.configMap.name: connectors-use-connectors-proxy-in-pod

该组合意味着：

查找与运行时对象关联的审批资源
等待审批结果为正面
仅向该特定运行时上下文授予绑定 Pod 的代理权限

connectors-approvals-in-pipeline 是核心 Connectors 组件安装的内置检查模板。在流水线场景中，它使用运行时 Pod 上下文通过 tekton.dev/pipelineRun 定位相关的 Tekton ApprovalTask。

connectors-use-connectors-proxy-in-pod 是核心 Connectors 组件安装的内置角色模板。它授予 connectors/proxy/v1/pod/{.object.metadata.namespace}/{.object.metadata.name} 权限，将权限绑定到运行时记录的特定 Pod 上下文。

您仍然使用常见配置模式中的 Connector 选择模式；区别在于访问是在检查成功后按运行时上下文授予。

示例

以下策略适用于 prod-harbor Connector。它不授予默认访问，而是等待内置流水线审批检查，然后授予绑定 Pod 的代理权限。

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

常见配置模式

选择要保护的 Connectors

AccessPolicy 仅匹配与策略同一命名空间中的 Connectors。

目标 Connectors 在 spec.connector 中定义：

留空以匹配命名空间内所有 Connectors
使用 names 指定特定 Connectors
使用 matchLabels 或 matchExpressions 指定 Connector 组

这是将一个策略映射到一个 Connector、部分 Connectors 或一个范围内所有 Connectors 的主要机制。

示例

匹配当前命名空间内所有 Connectors。

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: allow-team-a-proxy
  namespace: team-a
spec:
  connector: {}

按名称匹配一个特定 Connector。

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: prod-harbor-policy
  namespace: devops
spec:
  connector:
    names:
      - prod-harbor

在一个命名空间中匹配多个明确命名的 Connectors。

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: release-connectors
  namespace: devops
spec:
  connector:
    names:
      - prod-harbor
      - prod-gitlab

匹配命名空间中某个 ConnectorClass 的所有 Connectors。

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: all-oci-connectors
  namespace: devops
spec:
  connector:
    matchLabels:
      connectors.alauda.io/connectorclass: oci

通过自定义标签（如环境或用途）匹配部分 Connectors。

apiVersion: connectors.alauda.io/v1alpha1
kind: AccessPolicy
metadata:
  name: prod-release-connectors
  namespace: devops
spec:
  connector:
    matchExpressions:
      - key: env
        operator: In
        values:
          - prod
      - key: usage
        operator: In
        values:
          - release

选择哪些 ServiceAccounts 获得默认访问

使用 defaultPermission 时，bindingTemplate.serviceAccounts 定义哪些 ServiceAccounts 可以通过 Connectors Proxy 使用匹配的 Connector。

每个条目组合：

names：要绑定的 ServiceAccount 名称
namespaceSelector：这些 ServiceAccounts 所在的命名空间

当想允许选定命名空间中的所有 ServiceAccounts 时，names 列表留空。

示例

允许当前命名空间内所有 ServiceAccounts。这是命名空间级 Connector 的常见模式。

defaultPermission:
  roleTemplate:
    ref:
      configMap:
        name: connectors-use-connectors-proxy
  bindingTemplate:
    serviceAccounts:
      - names: []
        namespaceSelector:
          names:
            - devops

仅允许一个命名空间内选定的 ServiceAccounts，例如 devops 中的 builder 和 deployer。

defaultPermission:
  roleTemplate:
    ref:
      configMap:
        name: connectors-use-connectors-proxy
  bindingTemplate:
    serviceAccounts:
      - names:
          - builder
          - deployer
        namespaceSelector:
          names:
            - devops

允许一个项目中所有命名空间的所有 ServiceAccounts。当 Connector 在项目级别共享且项目命名空间带有 cpaas.io/project 标签时很有用。

defaultPermission:
  roleTemplate:
    ref:
      configMap:
        name: connectors-use-connectors-proxy
  bindingTemplate:
    serviceAccounts:
      - names: []
        namespaceSelector:
          matchLabels:
            cpaas.io/project: devops

允许一个项目中所有命名空间的某个命名 ServiceAccount，例如 devops 项目中的 builder。

defaultPermission:
  roleTemplate:
    ref:
      configMap:
        name: connectors-use-connectors-proxy
  bindingTemplate:
    serviceAccounts:
      - names:
          - builder
        namespaceSelector:
          matchLabels:
            cpaas.io/project: devops

允许集群中所有 ServiceAccounts。这适用于集群共享的 Connector。在这种情况下，AccessPolicy 必须创建在与共享 Connector 相同的命名空间中。

defaultPermission:
  roleTemplate:
    ref:
      configMap:
        name: connectors-use-connectors-proxy
  bindingTemplate:
    serviceAccounts:
      - names: []
        namespaceSelector: {}

状态

AccessPolicy.status 帮助运维人员确认策略是否按预期应用。

重要状态字段包括：

matchedConnectors：当前由 spec.connector 匹配的 Connectors
conditions：策略的调和状态

此状态有助于在调查运行时访问行为前确认是否选择了预期的 Connectors。

后续内容

了解单个运行时请求如何评估，请参见 AccessRequest
了解模式定义，请参见 AccessPolicy API Reference
回顾整体流程，请参见 Connectors Approval & Permission Gating
了解代理流量工作原理，请参见 Connectors Proxy
了解工作负载如何通过 Connectors CSI Driver 使用 Connectors
了解独立的 API 访问模型，请参见 Connector API

#AccessPolicy

#目录

#概述

#可用性

#理解 AccessPolicy

#“使用 Connector” 的含义

#AccessPolicy 的工作原理

#两种访问模型

#授予默认代理访问

#示例

#审批后授予访问

#示例

#常见配置模式

#选择要保护的 Connectors

#示例

#选择哪些 ServiceAccounts 获得默认访问

#示例

#状态

#后续内容