角色和角色¶

背景¶

在 Kubernetes 的最初设计中，Ingress 和 Service 资源基于这样一种使用模型：创建 Service 和 Ingress 的开发者控制其应用程序向用户定义和公开的所有方面。

然而，在实践中，集群及其基础设施往往是共享的，而最初的 Ingress 模型并没有很好地体现这一点。一个关键因素是，当基础设施共享时，并非所有使用基础设施的人都具有相同的关注点，为了成功，基础设施项目需要满足所有用户的需求。

这就提出了一项基本挑战：如何在提供基础设施用户所需灵活性的同时，又保持基础设施所有者的控制权？

网关 API 定义了几个不同的角色，每个角色都与一个相关的角色相关联，作为一种工具来呈现和讨论不同用户的不同需求，以平衡可用性、灵活性，和控制。网关 API 中的设计工作有意地以这些角色的形式呈现。

请注意，根据环境的不同，一个人可能最终承担多个角色，如下所述。

网关 API 定义了三个角色和角色

Ian (他/他) 是一个基础设施提供商，负责维护和管理一组基础设施，这些基础设施允许多个隔离的集群为多个租户提供服务。他不受任何单个租户的约束；相反，他关心所有租户的集体利益。Ian 通常会在云提供商（AWS、Azure、GCP 等）或 PaaS 提供商工作。
Chihiro (他们/他们) 是一个集群运营商，负责管理集群以确保它们满足其多个用户的需求。Chihiro 通常会关注策略、网络访问、应用程序权限等。同样，他们不受任何单个集群用户的约束；相反，他们需要确保集群满足所有用户的需求。
Ana (她/她) 是一个应用程序开发者，负责创建和管理在集群中运行的应用程序。从网关 API 的角度来看，Ana 将需要管理配置（例如超时、请求匹配/过滤）和服务组合（例如将路径路由到后端）。她在网关 API 角色中处于独特的地位，因为她关注的是她的应用程序旨在满足的业务需求，而不是 Kubernetes 或网关 API。事实上，Ana 可能会将网关 API 和 Kubernetes 视为实现目标的纯粹阻碍。

根据环境的不同，多个角色可以映射到同一个用户

为单个用户提供所有上述角色会复制自助服务模型，这实际上可能发生在一个在裸机上运行 Kubernetes 的小型创业公司中。
一个更典型的小型创业公司会使用来自云提供商的集群。在这种情况下，Ana 和 Chihiro 可能由同一个人体现，而 Ian 则是云提供商的员工（或自动化流程！）。
在一个更大的组织中，我们预计上述每个角色都将由一个独立的人员体现（最有可能在不同的组中工作，也许很少直接接触）。

RBAC（基于角色的访问控制）是 Kubernetes 授权中使用的标准。这允许用户配置谁可以在特定范围内对资源执行操作。我们预计每个角色都将大致映射到 Kubernetes 基于角色的认证 (RBAC) 系统中的一个Role，并定义资源模型的责任和分离。

在安全模型描述中进一步讨论了 RBAC。