安全模型¶

介绍¶

网关 API 旨在为典型组织中的每个角色启用细粒度的授权。

资源¶

网关 API 有 3 个主要的 API 资源

网关类定义了一组具有公共配置和行为的网关。
网关请求一个点，流量可以在该点处被转换为集群内的服务。
路由描述了通过网关传入的流量如何映射到服务。

角色和角色¶

网关 API 中有 3 个主要角色，如角色和角色中所述

Ian (he/him)：基础设施提供商
Chihiro (they/them)：集群运营商
Ana (she/her)：应用程序开发人员

RBAC¶

RBAC（基于角色的访问控制）是用于 Kubernetes 授权的标准。这允许用户配置谁可以在特定范围内的资源上执行操作。RBAC 可用于启用上面定义的每个角色。在大多数情况下，希望大多数角色都能读取所有资源，因此我们将重点介绍此模型的写入访问权限。

简单 3 层模型的写入权限¶

	网关类	网关	路由
基础设施提供商	是	是	是
集群运营商	否	是	是
应用程序开发人员	否	否	是

高级 4 层模型的写入权限¶

	网关类	网关	路由
基础设施提供商	是	是	是
集群运营商	有时	是	是
应用程序管理员	否	在指定的命名空间中	在指定的命名空间中
应用程序开发人员	否	否	在指定的命名空间中

跨命名空间边界¶

网关 API 提供了跨命名空间边界的新方法。这些跨命名空间功能非常强大，但需要谨慎使用，以避免意外暴露。原则上，每次允许跨越命名空间边界时，都需要在命名空间之间进行握手。有两种不同的方式可以做到这一点

1. 路由绑定¶

路由可以连接到不同命名空间中的网关。为此，网关所有者必须明确允许路由从其他命名空间绑定。这是通过在网关侦听器中配置 allowedRoutes 来实现的，其配置如下所示

namespaces:
  from: Selector
  selector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - foo
      - bar

这将允许来自“foo”和“bar”命名空间的路由附加到此网关侦听器。

其他标签的风险¶

虽然可以使用其他标签与此选择器一起使用，但这并不安全。虽然kubernetes.io/metadata.name标签始终在命名空间上设置为命名空间的名称，但其他标签没有相同的保证。如果您使用自定义标签，例如env，那么任何能够在您的集群中为命名空间添加标签的人实际上都可以更改您的网关支持的命名空间集。

2. 参考授权¶

在某些情况下，我们允许其他对象引用跨越命名空间边界。这包括网关引用 Secret 和路由引用后端（通常是服务）。在这些情况下，必要的握手是通过 ReferenceGrant 资源来实现的。该资源存在于目标命名空间中，可用于允许来自其他命名空间的引用。

例如，以下 ReferenceGrant 允许来自“prod”命名空间中的 HTTPRoute 对与 ReferenceGrant 相同命名空间中部署的服务的引用。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-prod-traffic
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: prod
  to:
  - group: ""
    kind: Service

有关 ReferenceGrant 的更多信息，请参阅我们的此资源的详细文档。

高级概念：限制网关类可以使用哪些命名空间¶

一些基础设施提供商或集群运营商可能希望限制网关类可以使用哪些命名空间。目前，我们还没有在 API 中为此提供解决方案。为此，我们建议使用策略代理，例如 Open Policy Agent 和 Gatekeeper 来执行这些类型的策略。作为参考，我们创建了一个配置示例，该示例可用于此目的。