引用授权¶

从 v0.6.0 开始的标准通道

ReferenceGrant 资源是 Beta 版本，并且自 v0.6.0 开始成为标准通道的一部分。有关发布通道的更多信息，请参阅我们的版本控制指南.

注意

此资源最初名为“ReferencePolicy”。它被重命名为“ReferenceGrant”以避免与策略附加混淆。

ReferenceGrant 可用于在网关 API 中启用跨命名空间引用。特别是，路由可以将流量转发到其他命名空间中的后端，或者网关可以引用其他命名空间中的秘密。

Reference Grant

在过去，我们发现跨命名空间边界转发流量是一个理想的功能，但在没有像 ReferenceGrant 这样的安全措施的情况下，漏洞可能会出现。

如果从其命名空间外部引用对象，则该对象的拥有者必须创建 ReferenceGrant 资源以显式允许该引用。如果没有 ReferenceGrant，跨命名空间引用将无效。

结构¶

从根本上说，ReferenceGrant 由两个列表组成，一个列表是引用可能来自的资源，另一个列表是可能被引用的资源。

from 列表允许您指定可能引用 to 列表中描述的项目的资源的组、种类和命名空间。

to 列表允许您指定可能被 from 列表中描述的项目引用的资源的组和种类。命名空间在 to 列表中不是必需的，因为 ReferenceGrant 只能用于允许引用与 ReferenceGrant 相同命名空间中的资源。

示例¶

以下示例显示了 foo 命名空间中的 HTTPRoute 如何引用 bar 命名空间中的服务。在此示例中，bar 命名空间中的 ReferenceGrant 显式允许从 foo 命名空间中的 HTTPRoute 引用服务。

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: foo
  namespace: foo
spec:
  rules:
  - matches:
    - path: /bar
    backendRefs:
      - name: bar
        namespace: bar
---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: bar
  namespace: bar
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: foo
  to:
  - group: ""
    kind: Service

API 设计决策¶

虽然 API 本质上很简单，但它有一些值得注意的决策

每个 ReferenceGrant 仅支持一个 From 和 To 部分。必须使用其他 ReferenceGrant 资源对其他信任关系进行建模。
资源名称有意地从 ReferenceGrant 的“From”部分中排除，因为它们很少提供任何有意义的保护。能够在命名空间内写入特定种类资源的用户始终可以重命名资源或更改资源的结构以匹配给定的授权。
每个“From”结构允许使用一个命名空间。尽管选择器更强大，但它会鼓励不必要的不安全配置。
这些资源的效果纯粹是累加的，它们相互叠加。这使得它们不可能相互冲突。

有关特定 ReferenceGrant 字段如何解释的更多详细信息，请参阅 API 规范。

实施指南¶

此 API 依赖于运行时验证。实现必须监视这些资源的更改，并在每次更改或删除后重新计算跨命名空间引用的有效性。

在传达跨命名空间引用的状态时，实现必须不要公开其他命名空间中资源存在的信息，除非存在允许进行引用的 ReferenceGrant。这意味着如果在没有 ReferenceGrant 的情况下对不存在的资源进行跨命名空间引用，任何状态条件或警告消息都需要关注 ReferenceGrant 不存在以允许此引用这一事实。不应提供关于引用的资源是否存在任何提示。

例外¶

跨命名空间路由 -> 网关绑定遵循稍微不同的模式，其中握手机制内置于网关资源中。有关该方法的更多信息，请参阅相关的安全模型文档。尽管在概念上类似于 ReferenceGrant，但此配置直接内置到网关侦听器中，并允许进行细粒度的每个侦听器配置，而这在使用 ReferenceGrant 时是不可能的。

在某些情况下，可能可以接受忽略 ReferenceGrant 而支持其他某些安全机制。只有在其他机制（如 NetworkPolicy）能够通过实现有效地限制跨命名空间引用时，才能这样做。

选择进行此例外的实现必须清楚地记录 ReferenceGrant 未被其实现所接受，并详细说明哪些替代安全措施可用。请注意，这不太可能适用于 API 的 Ingress 实现，并且不适用于所有网格实现。

有关跨命名空间引用所涉及风险的示例，请参阅 CVE-2021-25740。此 API 的实现需要非常小心地避免混淆代理攻击。ReferenceGrant 为此提供了安全保障。例外情况必须仅由绝对确信其他同样有效的安全措施已到位实施。

一致性级别¶

ReferenceGrant 支持是以下对象发起的跨命名空间引用的“核心”一致性级别要求

网关
GRPCRoute
HTTPRoute
TLSRoute
TCPRoute
UDPRoute

也就是说，所有实现必须将此流程用于网关和任何核心 xRoute 类型中的任何跨命名空间引用，除了上面例外部分中提到的内容。

其他“实现特定”对象和引用也必须将此流程用于跨命名空间引用，除了上面例外部分中提到的内容。

潜在的未来 API 组更改¶

ReferenceGrant 正在开始引起网关 API 和 SIG 网络用例之外的兴趣。此资源可能会转移到更中立的位置。ReferenceGrant API 的用户可能需要在将来某个时间点迁移到不同的 API 组（而不是 gateway.networking.k8s.io）。