OpenShift 文档正在迁移，很快将只能在 docs.redhat.com（所有 Red Hat 产品文档的中心）访问。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

理解身份验证

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

作为管理员，您可以配置 OpenShift Container Platform 的身份验证。

用户

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

可能存在几种类型的用户

用户类型 描述

普通用户

这是大多数交互式 OpenShift Container Platform 用户的表示方式。普通用户在第一次登录时会自动在系统中创建，也可以通过 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 Container Platform。没有身份验证或身份验证无效的 API 请求将被认证为由anonymous系统用户发出的请求。身份验证后，策略将决定用户被授权执行哪些操作。

组

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

除了显式定义的组之外，还有一些系统组或虚拟组，这些组由集群自动预配。

以下默认虚拟组最为重要

虚拟组 描述

system:authenticated

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

system:authenticated:oauth

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

system:unauthenticated

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

API 身份验证

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

OAuth 访问令牌

  • 使用<namespace_route>/oauth/authorize和<namespace_route>/oauth/token端点从 OpenShift Container Platform OAuth 服务器获取。

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

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

X.509 客户端证书

  • 需要与 API 服务器建立 HTTPS 连接。

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

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

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

如果没有提供访问令牌或证书，身份验证层会将system:anonymous虚拟用户和system:unauthenticated虚拟组分配给请求。这允许授权层确定匿名用户被允许发出哪些请求（如果有）。

OpenShift Container Platform OAuth 服务器

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

当某人请求新的 OAuth 令牌时，OAuth 服务器使用已配置的身份提供程序来确定发出请求的人的身份。

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

OAuth 令牌请求

每个 OAuth 令牌请求都必须指定将接收和使用该令牌的 OAuth 客户端。启动 OpenShift Container Platform 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 Container Platform 配置为针对后端身份提供程序验证凭据。对<namespace_route>/oauth/authorize的请求可以来自无法显示交互式登录页面的用户代理，例如 CLI。因此，OpenShift Container Platform 支持使用WWW-Authenticate挑战进行身份验证，以及交互式登录流程。

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

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

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

API 模拟

您可以将对 OpenShift Container Platform API 的请求配置为模拟它来自另一个用户。有关更多信息，请参阅 Kubernetes 文档中的用户模拟。

Prometheus 的身份验证指标

OpenShift Container Platform 在身份验证尝试期间捕获以下 Prometheus 系统指标：

  • openshift_auth_basic_password_count 计算oc login用户名和密码尝试的次数。

  • openshift_auth_basic_password_count_result 按结果（success或error）计算oc login用户名和密码尝试的次数。

  • openshift_auth_form_password_count 计算 Web 控制台登录尝试的次数。

  • openshift_auth_form_password_count_result 按结果（success或error）计算 Web 控制台登录尝试的次数。

  • openshift_auth_password_total 计算oc login和 Web 控制台登录尝试的总数。