×

要与 OpenShift Dedicated 交互,用户必须首先向集群进行身份验证。身份验证层识别与 OpenShift Dedicated API 请求关联的用户。然后,授权层使用有关请求用户的的信息来确定是否允许该请求。

用户

OpenShift Dedicated 中的用户是可以向 OpenShift Dedicated API 发出请求的实体。OpenShift Dedicated `User` 对象表示一个参与者,可以通过向其或其组添加角色来授予其系统中的权限。通常,这代表与 OpenShift Dedicated 交互的开发人员或管理员的帐户。

可能存在几种类型的用户

用户类型 描述

普通用户

这是大多数交互式 OpenShift Dedicated 用户的表示方式。普通用户在首次登录时会自动在系统中创建,也可以通过 API 创建。普通用户由 `User` 对象表示。例如:`joe` `alice`

系统用户

许多这样的用户在定义基础设施时会自动创建,主要目的是为了使基础设施能够安全地与 API 交互。它们包括集群管理员(拥有所有权限)、每个节点的用户、路由器和注册表使用的用户以及其他各种用户。最后,还有一个 `anonymous` 系统用户,默认情况下用于未经身份验证的请求。例如:`system:admin` `system:openshift-registry` `system:node:node1.example.com`

服务账号

这些是与项目关联的特殊系统用户;有些会在首次创建项目时自动创建,而项目管理员可以创建更多服务账号,以便定义对每个项目内容的访问权限。服务账号由 `ServiceAccount` 对象表示。例如:`system:serviceaccount:default:deployer` `system:serviceaccount:foo:builder`

每个用户必须以某种方式进行身份验证才能访问 OpenShift Dedicated。没有身份验证或身份验证无效的 API 请求将被认证为 `anonymous` 系统用户发出的请求。身份验证后,策略将决定用户被授权执行的操作。

用户可以分配到一个或多个,每个组代表一组特定用户。当管理授权策略以一次性向多个用户授予权限时,组非常有用,例如允许访问项目中的对象,而不是分别授予用户。

除了显式定义的组外,还有集群自动配置的系统组或虚拟组

以下默认虚拟组最重要

虚拟组 描述

system:authenticated

自动与所有已认证用户关联。

system:authenticated:oauth

自动与所有使用 OAuth 访问令牌进行身份验证的用户关联。

system:unauthenticated

自动与所有未经身份验证的用户关联。

API 认证

对 OpenShift Dedicated API 的请求使用以下方法进行身份验证

OAuth 访问令牌
  • 使用<namespace_route>/oauth/authorize<namespace_route>/oauth/token 端点从 OpenShift Dedicated OAuth 服务器获取。

  • 作为 `Authorization: Bearer…` 标头发送。

  • 对于 websocket 请求,作为 websocket 子协议标头以 `base64url.bearer.authorization.k8s.io.<base64url-encoded-token>` 的形式发送。

X.509 客户端证书
  • 需要与 API 服务器建立 HTTPS 连接。

  • 由 API 服务器根据受信任的证书颁发机构捆绑包进行验证。

  • API 服务器创建并分发证书给控制器以进行自我身份验证。

任何具有无效访问令牌或无效证书的请求都会被身份验证层以 `401` 错误拒绝。

如果没有提供访问令牌或证书,身份验证层将 `system:anonymous` 虚拟用户和 `system:unauthenticated` 虚拟组分配给请求。这允许授权层确定匿名用户是否被允许发出任何请求。

OpenShift Dedicated OAuth 服务器

OpenShift Dedicated 主节点包含一个内置的 OAuth 服务器。用户获取 OAuth 访问令牌以向 API 进行身份验证。

当用户请求新的 OAuth 令牌时,OAuth 服务器会使用已配置的身份提供程序来确定请求用户的身份。

然后,它确定该身份映射到的用户,为该用户创建一个访问令牌,并返回该令牌以供使用。

OAuth 令牌请求

每个 OAuth 令牌请求都必须指定将接收和使用该令牌的 OAuth 客户端。启动 OpenShift Dedicated API 时会自动创建以下 OAuth 客户端。

OAuth 客户端 用途

openshift-browser-client

使用能够处理交互式登录的用户代理,在<namespace_route>/oauth/token/request 请求令牌。[1]

openshift-challenging-client

使用能够处理WWW-Authenticate 质询的用户代理请求令牌。

  1. <namespace_route> 指的是命名空间路由。可以通过运行以下命令找到它:

    $ oc get route oauth-openshift -n openshift-authentication -o json | jq .spec.host

所有 OAuth 令牌请求都涉及对<namespace_route>/oauth/authorize 的请求。大多数身份验证集成会在该端点前面放置一个身份验证代理,或将 OpenShift Dedicated 配置为根据后端身份提供程序验证凭据。对<namespace_route>/oauth/authorize 的请求可以来自无法显示交互式登录页面的用户代理,例如 CLI。因此,OpenShift Dedicated 支持使用WWW-Authenticate 质询进行身份验证,以及交互式登录流程。

如果在<namespace_route>/oauth/authorize 端点前面放置了身份验证代理,它会向未经身份验证的非浏览器用户代理发送WWW-Authenticate 质询,而不是显示交互式登录页面或重定向到交互式登录流程。

为防止针对浏览器客户端的跨站点请求伪造 (CSRF) 攻击,只有在请求中包含X-CSRF-Token 头部时,才发送 Basic 身份验证质询。预期接收 Basic WWW-Authenticate 质询的客户端必须将此头部设置为非空值。

如果身份验证代理不支持WWW-Authenticate 质询,或者 OpenShift Dedicated 配置为使用不支持 WWW-Authenticate 质询的身份提供程序,则必须使用浏览器从<namespace_route>/oauth/token/request 手动获取令牌。