OpenShift Container Platform 4.7 认证和授权

OpenShift Container Platform 4.7 认证和授权 为用户和服务配置用户身份验证和访问控制 Last Updated: 2021-06-29

OpenShift Container Platform 4.7 认证和授权 为用户和服务配置用户身份验证和访问控制

法律通告 Copyright 2021 Red Hat, Inc. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. Linux is the registered trademark of Linus Torvalds in the United States and other countries. Java is a registered trademark of Oracle and/or its affiliates. XFS is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries. MySQL is a registered trademark of MySQL AB in the United States, the European Union and other countries. Node.js is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project. The OpenStack Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community. All other trademarks are the property of their respective owners. 摘要 本文档提供在 OpenShift Container Platform 中定义身份提供程序的说明 它还讨论如何配置基于角色的访问控制来保护集群的安全

目录 目录 第... 1. 章... 了解身份验证...................................................................................................... 5. 1.1. 用户 5 1.2. 组 5 1.3. API 身份验证 6 第... 2.. 章.. 配置内部......... OAUTH......... 服务器.................................................................................... 8. 2.1. OPENSHIFT CONTAINER PLATFORM OAUTH 服务器 8 2.2. OAUTH 令牌请求流量和响应 8 2.3. 内部 OAUTH 服务器选项 8 2.4. 配置内部 OAUTH 服务器的令牌期间 9 2.5. 为内部 OAUTH 服务器配置令牌不活跃超时 10 2.6. OAUTH 服务器元数据 11 2.7. OAUTH API 事件故障排除 12 第... 3.. 章.. 配置..... OAUTH........ 客户端........................................................................................ 15.. 3.1. 默认 OAUTH 客户端 15 3.2. 注册其他 OAUTH 客户端 15 3.3. 为 OAUTH 客户端配置令牌不活跃超时 16 3.4. 其他资源 16 第... 4.. 章.. 管理用户拥....... 户拥有的......... OAUTH........ 访问令牌............................................................................. 18.. 4.1. 列出用户拥有的 OAUTH 访问令牌 18 4.2. 查看用户拥有的 OAUTH 访问令牌的详情 18 4.3. 删除用户拥有的 OAUTH 访问令牌 19 第... 5.. 章.. 了解身份提供程序配置..................................................................................................... 21.. 5.1. 关于 OPENSHIFT CONTAINER PLATFORM 中的身份提供程序 21 5.2. 支持的身份提供程序 21 5.3. 移除 KUBEADMIN 用户 22 5.4. 身份提供程序参数 22 5.5. 身份提供程序 CR 示例 23 第... 6.. 章.. 配置身份提供程序..................................................................................................... 24.. 6.1. 配置 HTPASSWD 身份提供程序 24 6.2. 配置 KEYSTONE 身份提供程序 28 6.3. 配置 LDAP 身份提供程序 31 6.4. 配置基本身份验证身份提供程序 34 6.5. 配置请求标头身份提供程序 40 6.6. 配置 GITHUB 或 GITHUB ENTERPRISE 身份提供程序 47 6.7. 配置 GITLAB 身份提供程序 51 6.8. 配置 GOOGLE 身份提供程序 53 6.9. 配置 OPENID CONNECT 身份提供程序 56 第... 7.. 章.. 使用..... RBAC....... 定义和应用权限......................................................................................... 61.. 7.1. RBAC 概述 61 7.2. 项目和命名空间 64 7.3. 默认项目 65 7.4. 查看集群角色和绑定 65 7.5. 查看本地角色和绑定 72 7.6. 向用户添加角色 73 7.7. 创建本地角色 75 7.8. 创建集群角色 76 7.9. 本地角色绑定命令 76 1

OpenShift Container Platform 4.7 认证和授和授权 7.10. 集群角色绑定命令 7.11. 创建集群管理员 77 77 第... 8.. 章.. 移除..... KUBEADMIN.............. 用户.................................................................................. 78.. 8.1. KUBEADMIN 用户 78 8.2. 移除 KUBEADMIN 用户 78 第... 9.. 章.. 了解并创建服......... 建服务帐户............................................................................................ 79.. 9.1. 服务帐户概述 79 9.2. 创建服务帐户 79 9.3. 为服务帐户授予角色的示例 80 第... 10... 章.. 在应用程序中使用服..... 用程序中使用服务帐户............................................................................................... 82.. 10.1. 服务帐户概述 82 10.2. 默认服务帐户 82 10.3. 创建服务帐户 83 10.4. 在外部使用服务帐户凭证 84 第... 11.. 章... 使用服务帐户...... 务帐户作为........... OAUTH........ 客户端........................................................................... 86.. 11.1. 服务帐户作为 OAUTH 客户端 86 第... 12.. 章... 界定令牌作用域.................................................................................................... 89.. 12.1. 关于界定令牌作用域 89 第... 13... 章.. 使用绑定的服....... 定的服务帐户...... 务帐户令牌....................................................................................... 90.. 13.1. 关于绑定服务帐户令牌 90 13.2. 使用卷投射配置绑定服务帐户令牌 90 第... 14... 章.. 管理安全性上下文约束.................................................................................................... 92.. 14.1. 关于安全性上下文约束 92 14.2. 关于预分配安全性上下文约束值 97 14.3. 安全性上下文约束示例 98 14.4. 创建安全性上下文约束 100 14.5. 基于角色的对安全性上下文限制的访问 101 14.6. 安全性上下文约束参考命令 103 第... 15.. 章... 模拟..... SYSTEM:ADMIN................. 用户............................................................................. 106... 15.1. API 模仿 106 15.2. 模拟 SYSTEM:ADMIN 用户 106 15.3. 模拟 SYSTEM:ADMIN 组 106 第... 16... 章.. 同步..... LDAP...... 组........................................................................................ 107... 16.1. 关于配置 LDAP 同步 107 16.2. 运行 LDAP 同步 111 16.3. 运行组修剪任务 113 16.4. LDAP 组同步示例 113 16.5. LDAP 同步配置规格 125 第... 17.. 章... 创建和使用配置映射.................................................................................................... 131.. 17.1. 了解 CONFIGMAP 131 17.2. 在 OPENSHIFT CONTAINER PLATFORM WEB 控制台中创建配置映射 132 17.3. 创建配置映射 132 17.4. 使用案例 : 在 POD 中使用 CONFIGMAP 136 第... 18... 章.. 管理云供应商凭........... 商凭证........................................................................................ 142... 18.1. 关于 CLOUD CREDENTIAL OPERATOR 142 2

目录 18.2. 使用 MINT 模式 18.3. 使用 PASSTHROUGH 模式 18.4. 使用手动模式 18.5. 在 STS 中使用手动模式 143 147 149 150 3

OpenShift Container Platform 4.7 认证和授和授权 4

第 1 章了解身份验证 第 1 章了解身份验证 用户若要与 OpenShift Container Platform 交互, 必须先进行集群的身份验证 身份验证层识别与 OpenShift Container Platform API 请求关联的用户 然后, 授权层使用有关请求用户的信息来确定是否允许该请求 作为管理员, 您可以为 OpenShift Container Platform 配置身份验证 1.1. 用户 OpenShift Container Platform 中的用户是可以向 OpenShift Container Platform API 发出请求的实体 OpenShift Container Platform User 对象代表操作者, 通过向它们或所在的组添加角色为其授予系统中的权限 通常, 这代表与 OpenShift Container Platform 交互的开发人员或管理员的帐户 可能存在的用户类型有几种 : 用户类户类型 描述 常规用户 这是大多数交互式 OpenShift Container Platform 用户的类型 常规用户于第一次登录时在系统中自动创建, 或者也可通过 API 创建 常规用户通过 User 对象表示 例如,joe alice 系统用户 许多系统用户在基础架构定义时自动创建, 主要用于使基础架构与 API 安全地交互 这包括集群管理员 ( 有权访问一切资源 ) 特定于一个节点的用户 供路由器和 registry 使用的用户, 以及一些其他用户 最后, 还有一种 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 系统用户发出的请求 经过身份验证后, 策略决定用户被授权执行的操作 1.2. 组 用户可以分配到一个或多个组中, 每个组代表特定的用户集合 在管理授权策略时, 可使用组同时为多个用户授予权限, 例如允许访问一个项目中的多个对象, 而不必单独授予用户权限 除了明确定义的组外, 还有系统组或虚拟组, 它们由集群自动置备 以下列出了最重要的默认虚拟组 : 虚拟组 描述 system:authenticated 自动与所有经过身份验证的用户关联 5

OpenShift Container Platform 4.7 认证和授和授权 虚拟组 描述 system:authenticated:oa uth 自动与所有使用 OAuth 访问令牌经过身份验证的用户关联 system:unauthenticated 自动与所有未经身份验证的用户关联 1.3. API 身份验证 对 OpenShift Container Platform API 的请求通过以下方式进行身份验证 : OAuth 访问令牌 使用 <namespace_route>/oauth/authorize 和 <namespace_route>/oauth/token 端点, 从 OpenShift Container Platform OAuth 服务器获取 作为 Authorization: Bearer 标头形式发送 以 base64url.bearer.authorization.k8s.io.<base64url-encoded-token> 形式, 作为 websocket 请求的 websocket 子协议标头发送 X.509 客户端证书 需要与 API 服务器的 HTTPS 连接 由 API 服务器针对可信证书颁发机构捆绑包进行验证 API 服务器创建证书并分发到控制器, 以对自身进行身份验证 任何具有无效访问令牌或无效证书的请求都会被身份验证层以 401 错误形式拒绝 如果没有出示访问令牌或证书, 身份验证层会将 system:anonymous 虚拟用户和 system:unauthenticated 虚拟组分配给请求 这使得授权层能够决定匿名用户可以发出哪些 ( 如有 ) 请求 1.3.1. OpenShift Container Platform OAuth 服务器 OpenShift Container Platform master 包含内置的 OAuth 服务器 用户获取 OAuth 访问令牌来对自身进行 API 身份验证 有人请求新的 OAuth 令牌时,OAuth 服务器使用配置的身份提供程序来确定提出请求的人的身份 然后, 它会确定该身份所映射到的用户, 为该用户创建一个访问令牌, 再返回要使用的令牌 1.3.1.1. OAuth 令牌请求 每个对 OAuth 令牌的请求都必须指定要接收和使用令牌的 OAuth 客户端 启动 OpenShift Container Platform API 时会自动创建以下 OAuth 客户端 : 6

第 1 章了解身份验证 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 标头时, 仅发送基本身份验证质询 希望接收基本 WWW-Authenticate 质询的客户端必须将此标头设置为非空值 如果身份验证代理不支持 WWW-Authenticate 质询, 或者如果 OpenShift Container Platform 配置为使用不支持 WWW-Authenticate 质询的身份提供程序, 则必须使用浏览器从 <namespace_route>/oauth/token/request 手动获取令牌 1.3.1.2. API 模仿 您可以配置对 OpenShift Container Platform API 的请求, 使其表现为像是源自于另一用户 如需更多信息, 请参阅 Kubernetes 文档中的用户模仿 1.3.1.3. 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 控制台登录尝试总次数 7

OpenShift Container Platform 4.7 认证和授和授权 第 2 章配置内部 OAUTH 服务器 2.1. OPENSHIFT CONTAINER PLATFORM OAUTH 服务器 OpenShift Container Platform master 包含内置的 OAuth 服务器 用户获取 OAuth 访问令牌来对自身进行 API 身份验证 有人请求新的 OAuth 令牌时,OAuth 服务器使用配置的身份提供程序来确定提出请求的人的身份 然后, 它会确定该身份所映射到的用户, 为该用户创建一个访问令牌, 再返回要使用的令牌 2.2. OAUTH 令牌请求流量和响应 OAuth 服务器支持标准的授权代码授权和隐式授权 OAuth 授权流 在使用隐式授权流 (response_type=token) 以及配置为请求 WWW-Authenticate 质询 ( 如 openshiftchallenging-client) 的 client_id 以请求 OAuth 令牌时, 可能来自 /oauth/authorize 的服务器响应及它们的处理方式如下方所列 : 状态 内容 客户端响应 302 Location 标头包含 URL 片段中的 access_token 参数 (RFC 6749 4.2.2 部分 ) 使用 access_token 值作为 OAuth 令牌 302 Location 标头包含 error 查询参数 (RFC 6749 4.1.2.1 部分 ) 失败, 或向用户显示 error( 使用可选的 error_description) 查询值 302 其他 Location 标头接续重定向操作, 并使用这些规则处理结果 401 WWW-Authenticate 标头存在 在识别了类型时 ( 如 Basic 和 Negotiate 等 ) 响应质询, 重新提交请求, 再使用这些规则处 理结果 401 没有 WWW-Authenticate 标头 无法进行质询身份验证 失败, 并显示响应正 文 ( 可能包含用于获取 OAuth 令牌的链接或备 用方法详情 ) 其他其他失败, 或可向用户显示响应正文 2.3. 内部 OAUTH 服务器选项 内部 OAuth 服务器可使用几个配置选项 2.3.1. OAuth 令牌期间选项 内部 OAuth 服务器生成两种令牌 : 8

第 2 章配置内部 OAUTH 服务器 令牌 描述 访问令牌 存在时间较长的令牌, 用于授权对 API 的访问 授权代码 存在时间较短的令牌, 仅用于交换访问令牌 您可以为两种类型的令牌配置默认的期间 若有需要, 可使用 OAuthClient 对象定义覆盖访问令牌的期间 2.3.2. OAuth 授权选项 当 OAuth 服务器收到用户之前没有授予权限的客户端的令牌请求时,OAuth 服务器采取的操作取决于 OAuth 客户端的授权策略 请求令牌的 OAuth 客户端必须提供自己的授权策略 您可以应用以下默认方法 : 授权选项 描述 auto 自动批准授权并重试请求 prompt 提示用户批准或拒绝授权 2.4. 配置内部 OAUTH 服务器的令牌期间 您可以配置内部 OAuth 服务器令牌期间的默认选项 重要 默认情况下, 令牌仅在 24 小时内有效 现有会话会在此时间过后到期 如果默认时间不足, 可以使用以下步骤进行修改 流程 1. 创建一个包含令牌期间选项的配置文件 以下文件将此周期设为 48 小时, 两倍于默认值 apiversion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: tokenconfig: accesstokenmaxageseconds: 172800 1 1 设置 accesstokenmaxageseconds 以控制访问令牌的生命周期 默认生命周期为 24 小时或 86400 秒 此属性不可为负数 9

OpenShift Container Platform 4.7 认证和授和授权 2. 应用新配置文件 : 注意 由于您更新现有的 OAuth 服务器, 因此必须使用 oc apply 命令来应用更改 $ oc apply -f </path/to/file.yaml> 3. 确认更改已生效 : $ oc describe oauth.config.openshift.io/cluster 输出示例... Spec: Token Config: Access Token Max Age Seconds: 172800... 2.5. 为内部 OAUTH 服务器配置令牌不活跃超时 您可以将 OAuth 令牌配置为在一组不活跃时间后过期 默认情况下, 不会设置令牌不活跃超时 注意 如果您的 OAuth 客户端中也配置了令牌不活动超时, 则该值会覆盖内部 OAuth 服务器配置中设置的超时 先决条件 您可以使用具有 cluster-admin 角色的用户访问集群 您已经配置了一个身份提供程序 (IDP) 流程 1. 更新 OAuth 配置, 以设置令牌不活跃超时 a. 编辑 OAuth 对象 : $ oc edit oauth cluster 添加 spec.tokenconfig.accesstokeninactivitytimeout 字段并设置超时值 : apiversion: config.openshift.io/v1 kind: OAuth metadata:... spec: tokenconfig: accesstokeninactivitytimeout: 400s 1 10

第 2 章配置内部 OAUTH 服务器 1 设定有适当单位的值, 例如 400s 代表 400 秒, 或 30m 代表 30 分钟 允许的超时最小值为 300s b. 保存文件以使改变生效 2. 检查 OAuth 服务器 pod 是否已重启 : $ oc get clusteroperators authentication 在 PROGRESSING 列为 False 前不要继续进入下一步, 如下所示 : 输出示例 NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE authentication 4.7.0 True False False 145m 3. 检查是否已推出 Kubernetes API 服务器 pod 的新修订版本 这需要几分钟时间 $ oc get clusteroperators kube-apiserver 在 PROGRESSING 列为 False 前不要继续进入下一步, 如下所示 : 输出示例 NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE kube-apiserver 4.7.0 True False False 145m 如果 PROGRESSING 显示为 True, 请等待几分钟后再试一次 验证 1. 使用来自您的 IDP 的身份登录到集群 2. 执行命令并确认它是否成功 3. 等待的时间比配置的超时时间长而无需使用身份 在这个示例中, 等待的时间超过 400 秒 4. 尝试从同一身份的会话中执行命令 这个命令会失败, 因为令牌应该因为不活跃的时间超过配置的超时时间而过期 输出示例 error: You must be logged in to the server (Unauthorized) 2.6. OAUTH 服务器元数据 在 OpenShift Container Platform 中运行的应用程序可能需要发现有关内置 OAuth 服务器的信息 例如, 它们可能需要发现 <namespace_route> 的哪个地址没有手动配置 为此,OpenShift Container Platform 实施了 IETF OAuth 2.0 授权服务器元数据草案规范 因此, 集群中运行的任何应用程序都可以向 https://openshift.default.svc/.well-known/oauthauthorization-server 发出 GET 请求来获取以下信息 : 11

OpenShift Container Platform 4.7 认证和授和授权 { "issuer": "https://<namespace_route>", 1 "authorization_endpoint": "https://<namespace_route>/oauth/authorize", 2 "token_endpoint": "https://<namespace_route>/oauth/token", 3 "scopes_supported": [ 4 "user:full", "user:info", "user:check-access", "user:list-scoped-projects", "user:list-projects" ], "response_types_supported": [ 5 "code", "token" ], "grant_types_supported": [ 6 "authorization_code", "implicit" ], "code_challenge_methods_supported": [ 7 "plain", "S256" ] } 1 2 3 4 5 6 7 授权服务器的签发者标识符, 它是使用 https 方案且没有查询或分段组件的 URL 这是包含授权服务器有关信息的.well-known RFC 5785 资源的发布位置 授权服务器的授权端点的 URL 参见 RFC 6749 授权服务器的令牌端点的 URL 参见 RFC 6749 包含此授权服务器支持的 OAuth 2.0 RFC 6749 范围值列表的 JSON 数组 请注意, 并非所有支持的范围值都会公告 包含此授权服务器支持的 OAuth 2.0 response_type 值列表的 JSON 数组 使用的数组值与 response_types 参数 ( 根据 RFC 7591 中 OAuth 2.0 Dynamic Client Registration Protocol 定义 ) 使用的数组值相同 包含此授权服务器支持的 OAuth 2.0 授权类型值列表的 JSON 数组 使用的数组值与通过 grant_types 参数 ( 根据 RFC 7591 中 OAuth 2.0 Dynamic Client Registration Protocol 定义 ) 使用的数组值相同 包含此授权服务器支持的 PKCE RFC 7636 代码质询方法列表的 JSON 数组 code_challenge_method 参数中使用的代码质询方法值在 RFC 7636 第 4.3 节中定义 有效的代码质询方法值是在 IANA PKCE Code Challenge Methods 注册表中注册的值 请参阅 IANA OAuth 参数 2.7. OAUTH API 事件故障排除 在有些情况下,API 服务器会返回一个 unexpected condition 错误消息 ; 若不直接访问 API 主日志, 很难对此消息进行调试 该错误的基本原因被有意遮挡, 以避免向未经身份验证的用户提供有关服务器状态的信息 12

第 2 章配置内部 OAUTH 服务器 这些错误的子集与服务帐户 OAuth 配置问题有关 这些问题在非管理员用户可查看的事件中捕获 OAuth 期间遇到 unexpected condition 服务器错误时, 可运行 oc get events 在 ServiceAccount 下查看这些事件 以下示例警告缺少正确 OAuth 重定向 URI 的服务帐户 : $ oc get events grep ServiceAccount 输出示例 1m 1m 1 proxy ServiceAccount Warning NoSAOAuthRedirectURIs service-account-oauth-client-getter system:serviceaccount:myproject:proxy has no redirecturis; set serviceaccounts.openshift.io/oauthredirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference> 运行 oc describe sa/<service_account_name> 可以报告与给定服务帐户名称关联的任何 OAuth 事件 $ oc describe sa/proxy grep -A5 Events 输出示例 Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 3m 3m 1 service-account-oauth-client-getter Warning NoSAOAuthRedirectURIs system:serviceaccount:myproject:proxy has no redirecturis; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference> 下方列出可能的事件错误 : 无重定向 URI 注解或指定了无效的 URI Reason Message NoSAOAuthRedirectURIs system:serviceaccount:myproject:proxy has no redirecturis; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference> 指定了无效的路由 Reason Message NoSAOAuthRedirectURIs [routes.route.openshift.io "<name>" not found, system:serviceaccount:myproject:proxy has no redirecturis; set serviceaccounts.openshift.io/oauthredirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>] 指定了无效的引用类型 Reason Message NoSAOAuthRedirectURIs [no kind "<name>" is registered for version "v1", 13

OpenShift Container Platform 4.7 认证和授和授权 system:serviceaccount:myproject:proxy has no redirecturis; set serviceaccounts.openshift.io/oauthredirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>] 缺少 SA 令牌 Reason Message NoSAOAuthTokens system:serviceaccount:myproject:proxy has no tokens 14

第 3 章配置 OAUTH 客户端 第 3 章配置 OAUTH 客户端 在 OpenShift Container Platform 中默认创建多个 OAuth 客户端 您还可以注册和配置其他 OAuth 客户端 3.1. 默认 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 3.2. 注册其他 OAUTH 客户端 如果需要其他 OAuth 客户端来管理 OpenShift Container Platform 集群的身份验证, 则可以注册一个 流程 注册其他 OAuth 客户端 : $ oc create -f <(echo ' kind: OAuthClient apiversion: oauth.openshift.io/v1 metadata: name: demo 1 secret: "..." 2 redirecturis: - "http://www.example.com/" 3 grantmethod: prompt 4 ') 1 2 3 4 OAuth 客户端的 name 用作提交对 <namespace_route>/oauth/authorize 和 <namespace_route>/oauth/token 的请求时的 client_id 参数 secret 用作提交对 <namespace_route>/oauth/token 的请求时的 client_secret 参数 对 <namespace_route>/oauth/authorize 和 <namespace_route>/oauth/token 的请求中指定的 redirect_uri 参数必须等于 redirecturis 参数值中所列的某一 URI 或以其为前缀 grantmethod 用于确定当此客户端请求了令牌且还未被用户授予访问权限时应采取的操作 指定 auto 可自动批准授权并重试请求, 或指定 prompt 以提示用户批准或拒绝授权 15

OpenShift Container Platform 4.7 认证和授和授权 3.3. 为 OAUTH 客户端配置令牌不活跃超时 在一组不活跃的时间后, 您可以将 OAuth 客户端配置为使 OAuth 令牌过期 默认情况下, 不会设置令牌不活跃超时 注意 如果在内部 OAuth 服务器配置中也配置了令牌不活动超时,OAuth 客户端中设置的超时会覆盖该值 先决条件 您可以使用具有 cluster-admin 角色的用户访问集群 您已经配置了一个身份提供程序 (IDP) 流程 更新 OAuthClient 配置, 以设置令牌不活跃超时 a. 编辑 OAuthClient 对象 : $ oc edit oauthclient <oauth_client> 1 1 将 <oauth_client> 替换为要配置的 OAuth 客户端, 如控制台 添加 accesstokeninactivitytimeoutseconds 字段并设置您的超时值 : apiversion: oauth.openshift.io/v1 grantmethod: auto kind: OAuthClient metadata:... accesstokeninactivitytimeoutseconds: 600 1 1 允许的最小超时值 ( 以秒为单位 ) 为 300 b. 保存文件以使改变生效 验证 1. 使用来自您的 IDP 的身份登录到集群 确保使用您刚才配置的 OAuth 客户端 2. 执行操作并验证它是否成功 3. 等待的时间比配置的超时时间长而无需使用身份 在这个示例中, 等待会超过 600 秒 4. 尝试从同一身份的会话中执行一个操作 这个尝试会失败, 因为令牌应该因为不活跃的时间超过配置的超时时间而过期 3.4. 其他资源 16

第 3 章配置 OAUTH 客户端 OAuthClient [oauth.openshift.io/v1] 17

OpenShift Container Platform 4.7 认证和授和授权 第 4 章管理用户拥有的 OAUTH 访问令牌 用户可查看其自身 OAuth 访问令牌, 并删除不再需要的任何 OAuth 访问令牌 4.1. 列出用户拥有的 OAUTH 访问令牌 您可以列出用户拥有的 OAuth 访问令牌 令牌名称并不敏感, 它无法用于登录 流程 列出所有用户拥有的 OAuth 访问令牌 : $ oc get useroauthaccesstokens 输出示例 NAME CLIENT NAME CREATED EXPIRES REDIRECT URI SCOPES <token1> openshift-challenging-client 2021-01-11T19:25:35Z 2021-01-12 19:25:35 +0000 UTC https://oauth-openshift.apps.example.com/oauth/token/implicit user:full <token2> openshift-browser-client 2021-01-11T19:27:06Z 2021-01-12 19:27:06 +0000 UTC https://oauth-openshift.apps.example.com/oauth/token/display user:full <token3> console 2021-01-11T19:26:29Z 2021-01-12 19:26:29 +0000 UTC https://console-openshift-console.apps.example.com/auth/callback user:full 列出特定 OAuth 客户端的用户拥有的 OAuth 访问令牌 : $ oc get useroauthaccesstokens --field-selector=clientname="console" 输出示例 NAME CLIENT NAME CREATED EXPIRES REDIRECT URI SCOPES <token3> console 2021-01-11T19:26:29Z 2021-01-12 19:26:29 +0000 UTC https://console-openshift-console.apps.example.com/auth/callback user:full 4.2. 查看用户拥有的 OAUTH 访问令牌的详情 您可以查看用户拥有的 OAuth 访问令牌的详情 流程 描述用户拥有的 OAuth 访问令牌的详情 : $ oc describe useroauthaccesstokens <token_name> 输出示例 Name: <token_name> 1 Namespace: Labels: <none> 18

第 4 章管理用户拥户拥有的 OAUTH 访问令牌 Annotations: <none> API Version: oauth.openshift.io/v1 Authorize Token: sha256~ksckkug-9fg_rwn_auyspoig-_hqmfi9zul_cgd8wr8 Client Name: openshift-browser-client 2 Expires In: 86400 3 Inactivity Timeout Seconds: 317 4 Kind: UserOAuthAccessToken Metadata: Creation Timestamp: 2021-01-11T19:27:06Z Managed Fields: API Version: oauth.openshift.io/v1 Fields Type: FieldsV1 fieldsv1: f:authorizetoken: f:clientname: f:expiresin: f:redirecturi: f:scopes: f:username: f:useruid: Manager: oauth-server Operation: Update Time: 2021-01-11T19:27:06Z Resource Version: 30535 Self Link: /apis/oauth.openshift.io/v1/useroauthaccesstokens/<token_name> UID: f9d00b67-ab65-489b-8080-e427fa3c6181 Redirect URI: https://oauth-openshift.apps.example.com/oauth/token/display Scopes: user:full 5 User Name: <user_name> 6 User UID: 82356ab0-95f9-4fb3-9bc0-10f1d6a6a345 Events: <none> 1 2 3 4 5 6 令牌名称, 即令牌的 sha256 哈希 令牌名称并不敏感, 它无法用于登录 客户端名称, 用于描述令牌来自哪里 从令牌创建到令牌过期间的时间 ( 以秒为单位 ) 如果为 OAuth 服务器设置了令牌不活跃超时, 则这是从创建到不再使用该令牌间的时间 此令牌的范围 与此令牌关联的用户名 4.3. 删除用户拥有的 OAUTH 访问令牌 oc logout 命令只使活跃会话的 OAuth 令牌无效 您可以使用以下步骤删除不再需要的用户拥有的 OAuth 令牌 从使用该令牌的所有会话中删除 OAuth 访问令牌日志 流程 19

OpenShift Container Platform 4.7 认证和授和授权 删除用户拥有的 OAuth 访问令牌 : $ oc delete useroauthaccesstokens <token_name> 输出示例 useroauthaccesstoken.oauth.openshift.io "<token_name>" deleted 20

第 5 章了解身份提供程序配置 第 5 章了解身份提供程序配置 OpenShift Container Platform master 包含内置的 OAuth 服务器 开发人员和管理员获取 OAuth 访问令牌, 以完成自身的 API 身份验证 作为管理员, 您可以在安装集群后通过配置 OAuth 来指定身份提供程序 5.1. 关于 OPENSHIFT CONTAINER PLATFORM 中的身份提供程序 默认情况下, 集群中只有 kubeadmin 用户 要指定身份提供程序, 您必须创建一个自定义资源 (CR) 来描述该身份提供程序并把它添加到集群中 注意 OpenShift Container Platform 用户名不能包括 / : 和 % 5.2. 支持的身份提供程序 您可以配置以下类型的身份提供程序 : 用户身份提供程序 描述 HTPasswd 配置 htpasswd 身份提供程序, 针对使用 htpasswd 生成的文件验证用户名和密码 Keystone 配置 keystone 身份提供程序, 将 OpenShift Container Platform 集群与 Keystone 集成以启用共享身份验证, 用配置的 OpenStack Keystone v3 服务器将用户存储到内部数据库中 LDAP 配置 ldap 身份提供程序, 使用简单绑定身份验证来针对 LDAPv3 服务器验证用户名和密码 基本身份验证 (Basic authentication) 配置 basic-authentication 身份提供程序, 以便用户使用针对远程身份提供程序验证的凭证来登录 OpenShift Container Platform 基本身份验证是一种通用后端集成机制 请求标头 (Request header) 配置 request-header 身份提供程序, 标识请求标头值中的用户, 例如 X-Remote- User 它通常与设定请求标头值的身份验证代理一起使用 Github 或 GitHub Enterprise 配置 github 身份提供程序, 针对 GitHub 或 GitHub Enterprise 的 OAuth 身份验证服务器验证用户名和密码 GitLab 配置 gitlab 身份提供程序, 使用 GitLab.com 或任何其他 GitLab 实例作为身份提供程序 Google 配置 google 身份提供程序, 使用 Google 的 OpenID Connect 集成 OpenID Connect 配置 oidc 身份提供程序, 使用授权代码流与 OpenID Connect 身份提供程序集成 定义了身份提供程序后, 可以使用 RBAC 来定义并应用权限 21

OpenShift Container Platform 4.7 认证和授和授权 5.3. 移除 KUBEADMIN 用户 在定义了身份提供程序并创建新的 cluster-admin 用户后, 您可以移除 kubeadmin 来提高集群安全性 警告 如果在另一用户成为 cluster-admin 前按照这个步骤操作, 则必须重新安装 OpenShift Container Platform 此命令无法撤销 先决条件 必须至少配置了一个身份提供程序 必须向用户添加了 cluster-admin 角色 必须已经以管理员身份登录 流程 移除 kubeadmin Secret: $ oc delete secrets kubeadmin -n kube-system 5.4. 身份提供程序参数 以下是所有身份提供程序通用的参数 : 参数 描述 name 此提供程序名称作为前缀放在提供程序用户名前, 以此组成身份名称 22

第 5 章了解身份提供程序配置 参数 描述 mappingmethod 定义在用户登录时如何将新身份映射到用户 输入以下值之一 : claim 默认值 使用身份的首选用户名置备用户 如果具有该用户名的用户已映射到另一身份, 则失败 lookup 查找现有的身份 用户身份映射和用户, 但不自动置备用户或身份 这允许集群管理员手动或使用外部流程设置身份和用户 使用此方法需要手动置备用户 generate add 使用身份的首选用户名置备用户 如果拥有首选用户名的用户已映射到现有的身份, 则生成一个唯一用户名 例如 :myuser2 此方法不应与需要在 OpenShift Container Platform 用户名和身份提供程序用户名 ( 如 LDAP 组同步 ) 之间完全匹配的外部流程一同使用 使用身份的首选用户名置备用户 如果已存在具有该用户名的用户, 此身份将映射到现有用户, 添加到该用户的现有身份映射中 如果配置了多个身份提供程序并且它们标识同一组用户并映射到相同的用户名, 则需要进行此操作 注意 在添加或更改身份提供程序时, 您可以通过把 mappingmethod 参数设置为 add, 将新提供程序中的身份映射到现有的用户 5.5. 身份提供程序 CR 示例 以下自定义资源 (CR) 显示用来配置身份提供程序的参数和默认值 示例中使用了 HTPasswd 身份提供程序 身份提供程序 CR 示例 apiversion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityproviders: - name: my_identity_provider 1 mappingmethod: claim 2 type: HTPasswd htpasswd: filedata: name: htpass-secret 3 1 2 3 此提供程序名称作为前缀放在提供程序用户名前, 以此组成身份名称 控制如何在此提供程序的身份和 User 对象之间建立映射 包含使用 htpasswd 生成的文件的现有 secret 23

OpenShift Container Platform 4.7 认证和授和授权 6.1. 配置 HTPASSWD 身份提供程序 第 6 章配置身份提供程序 6.1.1. 关于 OpenShift Container Platform 中的身份提供程序 默认情况下, 集群中只有 kubeadmin 用户 要指定身份提供程序, 您必须创建一个自定义资源 (CR) 来描述该身份提供程序并把它添加到集群中 注意 OpenShift Container Platform 用户名不能包括 / : 和 % 要定义 HTPasswd 身份提供程序, 您必须执行以下步骤 : 1. 创建一个 htpasswd 文件来存储用户和密码信息 Linux 和 Windows 的操作说明 2. 创建一个 OpenShift Container Platform secret 来代表 htpasswd 文件 3. 定义 HTPasswd 身份提供程序资源 4. 将资源应用到默认的 OAuth 配置 6.1.2. 使用 Linux 创建 HTPasswd 文件 要使用 HTPasswd 身份提供程序, 您必须使用 htpasswd 生成一个包含集群用户名和密码的文件 先决条件 能够访问 htpasswd 实用程序 在 Red Hat Enterprise Linux 上, 安装 httpd-tools 软件包即可使用该实用程序 流程 1. 创建或更新含有用户名和散列密码的平面文件 : $ htpasswd -c -B -b </path/to/users.htpasswd> <user_name> <password> 该命令将生成散列版本的密码 例如 : $ htpasswd -c -B -b users.htpasswd user1 MyPassword! 输出示例 Adding password for user user1 2. 继续向文件中添加或更新凭证 : $ htpasswd -B -b </path/to/users.htpasswd> <user_name> <password> 24

第 6 章配置身份提供程序 6.1.3. 使用 Windows 创建 HTPasswd 文件 要使用 HTPasswd 身份提供程序, 您必须使用 htpasswd 生成一个包含集群用户名和密码的文件 先决条件 能够访问 htpasswd.exe 许多 Apache httpd 发行版本的 \bin 目录中均包含此文件 流程 1. 创建或更新含有用户名和散列密码的平面文件 : > htpasswd.exe -c -B -b <\path\to\users.htpasswd> <user_name> <password> 该命令将生成散列版本的密码 例如 : > htpasswd.exe -c -B -b users.htpasswd user1 MyPassword! 输出示例 Adding password for user user1 2. 继续向文件中添加或更新凭证 : > htpasswd.exe -b <\path\to\users.htpasswd> <user_name> <password> 6.1.4. 创建 HTPasswd secret 要使用 HTPasswd 身份提供程序, 您必须定义一个含有 HTPasswd 用户文件的 secret 先决条件 创建 HTPasswd 文件 流程 创建一个含有 HTPasswd 用户文件的 OpenShift Container Platform Secret $ oc create secret generic htpass-secret --from-file=htpasswd=</path/to/users.htpasswd> -n openshift-config 注意 包含 --from-file 参数的用户文件的 secret 键必须命名为 htpasswd, 如上述命令所示 6.1.5. HTPasswd CR 示例 以下自定义资源 (CR) 显示了 HTPasswd 身份提供程序的参数和可接受值 25

OpenShift Container Platform 4.7 认证和授和授权 HTPasswd CR apiversion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityproviders: - name: my_htpasswd_provider 1 mappingmethod: claim 2 type: HTPasswd htpasswd: filedata: name: htpass-secret 3 1 2 3 此提供程序名称作为前缀放在提供程序用户名前, 以此组成身份名称 控制如何在此提供程序的身份和 User 对象之间建立映射 包含使用 htpasswd 生成的文件的现有 secret 其他资源 有关适用于所有身份供应商的参数 ( 如 mappingmethod) 信息, 请参阅身份供应商参数 6.1.6. 将身份提供程序添加到集群中 安装集群之后, 请在其中添加一个身份提供程序, 以便您的用户可以进行身份验证 先决条件 创建 OpenShift Container Platform 集群 为身份提供程序创建自定义资源 (CR) 必须已经以管理员身份登录 流程 1. 应用定义的 CR: $ oc apply -f </path/to/cr> 注意 如果一个 CR 不存在,oc apply 会创建一个新的 CR, 并可能会触发以下警告 Warning: oc apply should be used on resources created by either oc create --save-config or oc apply 在这种情况下, 您可以忽略这个警告 2. 以来自身份提供程序的用户身份登录集群, 并在提示时输入密码 $ oc login -u <username> 26

第 6 章配置身份提供程序 3. 确认用户登录成功, 并显示用户名 $ oc whoami 6.1.7. 为 HTPasswd 身份提供程序更新用户 您可以从现有的 HTPasswd 身份提供程序中添加或删除用户 先决条件 您已创建了包含 HTPasswd 用户文件的 Secret 对象 这里假定它名为 htpass-secret 您已配置了一个 HTPasswd 身份提供程序 这里假定它名为 my_htpasswd_provider 您可以使用 htpasswd 工具程序 在 Red Hat Enterprise Linux 上, 安装 httpd-tools 软件包即可使用该实用程序 您需要有集群管理员特权 流程 1. 从 htpass-secret Secret 对象中检索 HTPasswd 文件, 并将该文件保存到您的文件系统中 : $ oc get secret htpass-secret -ojsonpath={.data.htpasswd} -n openshift-config base64 -- decode > users.htpasswd 2. 从 users.htpasswd 文件中添加或删除用户 添加一个新用户 : $ htpasswd -bb users.htpasswd <username> <password> 输出示例 Adding password for user <username> 删除一个现有用户 : $ htpasswd -D users.htpasswd <username> 输出示例 Deleting password for user <username> 3. 将 htpass-secret Secret 对象替换为 users.htpasswd 文件中更新的用户 : $ oc create secret generic htpass-secret --from-file=htpasswd=users.htpasswd --dryrun=client -o yaml -n openshift-config oc replace -f - 4. 如果删除了一个或多个用户, 您还需要为每个用户删除其现有资源 a. 删除 User 对象 : 27

OpenShift Container Platform 4.7 认证和授和授权 $ oc delete user <username> 输出示例 user.user.openshift.io "<username>" deleted 请确认已删除了用户, 否则如果用户的令牌还没有过期, 则用户还可以继续使用其令牌 b. 删除用户的 Identity 对象 : $ oc delete identity my_htpasswd_provider:<username> 输出示例 identity.user.openshift.io "my_htpasswd_provider:<username>" deleted 6.1.8. 使用 web 控制台配置身份提供程序 通过 web 控制台而非 CLI 配置身份提供程序 (IDP) 先决条件 您必须以集群管理员身份登录到 web 控制台 流程 1. 导航至 Administration Cluster Settings 2. 在 Global Configuration 选项卡下, 点 OAuth 3. 在 Identity Providers 部分中, 从 Add 下拉菜单中选择您的身份提供程序 注意 您可以通过 web 控制台来指定多个 IDP, 而不会覆盖现有的 IDP 6.2. 配置 KEYSTONE 身份提供程序 配置 keystone 身份提供程序, 将 OpenShift Container Platform 集群与 Keystone 集成以启用共享身份验证, 用配置的 OpenStack Keystone v3 服务器将用户存储到内部数据库中 此配置允许用户使用其 Keystone 凭证登录 OpenShift Container Platform Keystone 是一个提供身份 令牌 目录和策略服务的 OpenStack 项目 您可以配置与 Keystone 的集成, 以便 OpenShift Container Platform 的新用户基于 Keystone 用户名或者唯一 Keystone ID 使用这两种方法时, 用户可以输入其 Keystone 用户名和密码进行登录 使 OpenShift Container Platform 用户基于 Keystone ID 更为安全 如果删除了某一 Keystone 用户并使用其用户名创建了新的 Keystone 用户, 新用户或许能够访问旧用户的资源 6.2.1. 关于 OpenShift Container Platform 中的身份提供程序 28 kubeadmin

第 6 章配置身份提供程序 默认情况下, 集群中只有 kubeadmin 用户 要指定身份提供程序, 您必须创建一个自定义资源 (CR) 来描述该身份提供程序并把它添加到集群中 注意 OpenShift Container Platform 用户名不能包括 / : 和 % 6.2.2. 创建 secret 身份提供程序使用 openshift-config 命名空间中的 OpenShift Container Platform Secret 对象来包含客户端 secret 客户端证书和密钥 您可以使用以下命令, 定义一个包含字符串的 OpenShift Container Platform Secret 对象 $ oc create secret generic <secret_name> --from-literal=clientsecret=<secret> -n openshiftconfig 您可以使用以下命令, 定义一个文件 ( 如证书文件 ) 内容的 OpenShift Container Platform Secret $ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config 6.2.3. 创建配置映射 身份提供程序使用 openshift-config 命名空间中的 OpenShift Container Platform ConfigMap 对象来包含证书颁发机构捆绑包 主要用于包含身份提供程序所需的证书捆绑包 流程 使用以下命令, 定义包含证书颁发机构的 OpenShift Container Platform ConfigMap 证书颁发机构必须存储在 ConfigMap 对象的 ca.crt 键中 $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config 6.2.4. Keystone CR 示例 以下自定义资源 (CR) 显示 Keystone 身份提供程序的参数和可接受值 Keystone CR apiversion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityproviders: - name: keystoneidp 1 mappingmethod: claim 2 type: Keystone keystone: domainname: default 3 url: https://keystone.example.com:5000 4 29

OpenShift Container Platform 4.7 认证和授和授权 ca: 5 name: ca-config-map tlsclientcert: 6 name: client-cert-secret tlsclientkey: 7 name: client-key-secret 1 2 3 4 5 6 7 此提供程序名称作为前缀放在提供程序用户名前, 以此组成身份名称 控制如何在此提供程序的身份和 User 对象之间建立映射 Keystone 域名 在 Keystone 中, 用户名是特定于域的 只支持一个域 用于连接到 Keystone 服务器的 URL( 必需 ) 这必须使用 https 可选 : 对包含 PEM 编码证书颁发机构捆绑包的 OpenShift Container Platform ConfigMap 的引用, 以用于验证所配置 URL 的服务器证书 可选 : 对包含客户端证书的 OpenShift Container Platform Secret 对象的引用, 该证书在向所配置的 URL 发出请求时出示 对包含客户端证书密钥的 OpenShift Container Platform Secret 对象的引用 指定了 tlsclientcert 时必需此项 其他资源 有关适用于所有身份供应商的参数 ( 如 mappingmethod) 信息, 请参阅身份供应商参数 6.2.5. 将身份提供程序添加到集群中 安装集群之后, 请在其中添加一个身份提供程序, 以便您的用户可以进行身份验证 先决条件 创建 OpenShift Container Platform 集群 为身份提供程序创建自定义资源 (CR) 必须已经以管理员身份登录 流程 1. 应用定义的 CR: $ oc apply -f </path/to/cr> 注意 如果一个 CR 不存在,oc apply 会创建一个新的 CR, 并可能会触发以下警告 Warning: oc apply should be used on resources created by either oc create --save-config or oc apply 在这种情况下, 您可以忽略这个警告 2. 以来自身份提供程序的用户身份登录集群, 并在提示时输入密码 30

第 6 章配置身份提供程序 $ oc login -u <username> 3. 确认用户登录成功, 并显示用户名 $ oc whoami 6.3. 配置 LDAP 身份提供程序 配置 ldap 身份提供程序, 使用简单绑定身份验证来针对 LDAPv3 服务器验证用户名和密码 6.3.1. 关于 OpenShift Container Platform 中的身份提供程序 默认情况下, 集群中只有 kubeadmin 用户 要指定身份提供程序, 您必须创建一个自定义资源 (CR) 来描述该身份提供程序并把它添加到集群中 注意 OpenShift Container Platform 用户名不能包括 / : 和 % 6.3.2. 关于 LDAP 身份验证 在身份验证过程中, 搜索 LDAP 目录中与提供的用户名匹配的条目 如果找到一个唯一匹配项, 则尝试使用该条目的可分辨名称 (DN) 以及提供的密码进行简单绑定 执行下面这些步骤 : 1. 通过将配置的 url 中的属性和过滤器与用户提供的用户名组合来生成搜索过滤器 2. 使用生成的过滤器搜索目录 如果搜索返回的不是一个条目, 则拒绝访问 3. 尝试使用搜索所获条目的 DN 和用户提供的密码绑定到 LDAP 服务器 4. 如果绑定失败, 则拒绝访问 5. 如果绑定成功, 则将配置的属性用作身份 电子邮件地址 显示名称和首选用户名来构建一个身份 配置的 url 是 RFC 2255 URL, 指定要使用的 LDAP 主机和搜索参数 URL 的语法是 : ldap://host:port/basedn?attribute?scope?filter 在这个 URL 中 : URL 组件 描述 ldap 对于常规 LDAP, 使用 ldap 字符串 对于安全 LDAP (LDAPS), 改为使用 ldaps host:port LDAP 服务器的名称和端口 LDAP 默认为 localhost:389,ldaps 则默认为 localhost:636 31

OpenShift Container Platform 4.7 认证和授和授权 URL 组件 描述 basedn 所有搜索都应从中开始的目录分支的 DN 至少, 这必须是目录树的顶端, 但也可指定目录中的子树 attribute 要搜索的属性 虽然 RFC 2255 允许使用逗号分隔属性列表, 但无论提供多少个属性, 都仅使用第一个属性 如果没有提供任何属性, 则默认使用 uid 建议选择一个在您使用的子树中的所有条目间是唯一的属性 scope 搜索的范围 可以是 one 或 sub 如果未提供范围, 则默认使用 sub 范围 filter 有效的 LDAP 搜索过滤器 如果未提供, 则默认为 (objectclass=*) 在进行搜索时, 属性 过滤器和提供的用户名会组合在一起, 创建类似如下的搜索过滤器 : (&(<filter>)(<attribute>=<username>)) 例如, 可考虑如下 URL: ldap://ldap.example.com/o=acme?cn?sub?(enabled=true) 当客户端尝试使用用户名 bob 连接时, 生成的搜索过滤器将为 (&(enabled=true)(cn=bob)) 如果 LDAP 目录需要身份验证才能搜索, 请指定用于执行条目搜索的 binddn 和 bindpassword 6.3.3. 创建 LDAP secret 要使用身份提供程序, 您必须定义一个包含 bindpassword 字段的 OpenShift Container Platform Secret 对象 定义包含 bindpassword 字段的 OpenShift Container Platform Secret 对象 $ oc create secret generic ldap-secret --from-literal=bindpassword=<secret> -n openshiftconfig 注意 包含 --from-literal 参数的 bindpassword 的 secret 键必须名为 bindpassword, 如上述命令所示 6.3.4. 创建配置映射 身份提供程序使用 openshift-config 命名空间中的 OpenShift Container Platform ConfigMap 对象来包含证书颁发机构捆绑包 主要用于包含身份提供程序所需的证书捆绑包 流程 使用以下命令, 定义包含证书颁发机构的 OpenShift Container Platform ConfigMap 证书颁发机构必须存储在 ConfigMap 对象的 ca.crt 键中 32

第 6 章配置身份提供程序 $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config 6.3.5. LDAP CR 示例 以下自定义资源 (CR) 显示 LDAP 身份提供程序的参数和可接受值 LDAP CR apiversion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityproviders: - name: ldapidp 1 mappingmethod: claim 2 type: LDAP ldap: attributes: id: 3 - dn email: 4 - mail name: 5 - cn preferredusername: 6 - uid binddn: "" 7 bindpassword: 8 name: ldap-secret ca: 9 name: ca-config-map insecure: false 10 url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid" 11 1 2 3 4 5 6 7 8 此提供程序名称作为前缀放在返回的用户 ID 前, 以此组成身份名称 控制如何在此提供程序的身份和 User 对象之间建立映射 用作身份的属性列表 使用第一个非空属性 至少需要一个属性 如果列出的属性都没有值, 身份验证会失败 定义属性按原样检索, 允许使用二进制值 用作电子邮件地址的属的列表 使用第一个非空属性 用作显示名称的属性列表 使用第一个非空属性 为此身份置备用户时用作首选用户名的属性列表 使用第一个非空属性 在搜索阶段用来绑定的可选 DN 如果定义了 bindpassword, 则必须设置此项 对包含绑定密码的 OpenShift Container Platform Secret 对象的可选引用 如果定义了 binddn, 则必须设置此项 33

OpenShift Container Platform 4.7 认证和授和授权 9 10 11 可选 : 对包含 PEM 编码证书颁发机构捆绑包的 OpenShift Container Platform ConfigMap 的引用, 以用于验证所配置 URL 的服务器证书 仅在 insecure 为 false 时使用 为 true 时, 不会对服务器进行 TLS 连接 为 false 时,ldaps:// URL 使用 TLS 进行连接, 并且 ldap:// URL 升级到 TLS 当使用 ldaps:// URL 时, 此项必须设为 false, 因为这些 URL 始终会尝试使用 TLS 进行连接 RFC 2255 URL, 指定要使用的 LDAP 主机和搜索参数 注意 要将用户列在 LDAP 集成的白名单中, 请使用 lookup 映射方法 在允许从 LDAP 登录前, 集群管理员必须为每个 LDAP User 创建一个 Identity 对象和用户对象 其他资源 有关适用于所有身份供应商的参数 ( 如 mappingmethod) 信息, 请参阅身份供应商参数 6.3.6. 将身份提供程序添加到集群中 安装集群之后, 请在其中添加一个身份提供程序, 以便您的用户可以进行身份验证 先决条件 创建 OpenShift Container Platform 集群 为身份提供程序创建自定义资源 (CR) 必须已经以管理员身份登录 流程 1. 应用定义的 CR: $ oc apply -f </path/to/cr> 注意 如果一个 CR 不存在,oc apply 会创建一个新的 CR, 并可能会触发以下警告 Warning: oc apply should be used on resources created by either oc create --save-config or oc apply 在这种情况下, 您可以忽略这个警告 2. 以来自身份提供程序的用户身份登录集群, 并在提示时输入密码 $ oc login -u <username> 3. 确认用户登录成功, 并显示用户名 $ oc whoami 6.4. 配置基本身份验证身份提供程序 34

第 6 章配置身份提供程序 配置 basic-authentication 身份提供程序, 以便用户使用针对远程身份提供程序验证的凭证来登录 OpenShift Container Platform 基本身份验证是一种通用后端集成机制 6.4.1. 关于 OpenShift Container Platform 中的身份提供程序 默认情况下, 集群中只有 kubeadmin 用户 要指定身份提供程序, 您必须创建一个自定义资源 (CR) 来描述该身份提供程序并把它添加到集群中 注意 OpenShift Container Platform 用户名不能包括 / : 和 % 6.4.2. 关于基本身份验证 基本身份验证是一种通用后端集成机制, 用户可以使用针对远程身份提供程序验证的凭证来登录 OpenShift Container Platform 由于基本身份验证是通用的, 因此您可以在高级身份验证配置中使用此身份提供程序 重要 基本身份验证必须使用 HTTPS 连接到远程服务器, 以防止遭受用户 ID 和密码嗅探以及中间人攻击 配置了基本身份验证后, 用户将其用户名和密码发送到 OpenShift Container Platform, 然后通过提出服务器对服务器请求并将凭证作为基本身份验证标头来传递, 针对远程服务器验证这些凭证 这要求用户在登录期间向 OpenShift Container Platform 发送凭证 注意 这只适用于用户名 / 密码登录机制, 并且 OpenShift Container Platform 必须能够向远程身份验证服务器发出网络请求 针对受基本身份验证保护并返回 JSON 的远程 URL 验证用户名和密码 401 响应表示身份验证失败 非 200 状态或出现非空 error 键表示出现错误 : {"error":"error message"} 200 状态并带有 sub(subject) 键则表示成功 : {"sub":"userid"} 1 1 主体必须是经过身份验证的用户所特有的, 而且必须不可修改 成功响应可以有选择地提供附加数据, 例如 : 使用 name 键的显示名称 例如 : {"sub":"userid", "name": "User Name",...} 35

OpenShift Container Platform 4.7 认证和授和授权 使用 email 键的电子邮件地址 例如 : {"sub":"userid", "email":"user@example.com",...} 使用 preferred_username 键的首选用户名 这可用在唯一不可改主体是数据库密钥或 UID 且存在更易读名称的情形中 为经过身份验证的身份置备 OpenShift Container Platform 用户时, 这可用作提示 例如 : {"sub":"014fbff9a07c", "preferred_username":"bob",...} 6.4.3. 创建 secret 身份提供程序使用 openshift-config 命名空间中的 OpenShift Container Platform Secret 对象来包含客户端 secret 客户端证书和密钥 您可以使用以下命令, 定义一个包含字符串的 OpenShift Container Platform Secret 对象 $ oc create secret generic <secret_name> --from-literal=clientsecret=<secret> -n openshiftconfig 您可以使用以下命令, 定义一个文件 ( 如证书文件 ) 内容的 OpenShift Container Platform Secret $ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config 6.4.4. 创建配置映射 身份提供程序使用 openshift-config 命名空间中的 OpenShift Container Platform ConfigMap 对象来包含证书颁发机构捆绑包 主要用于包含身份提供程序所需的证书捆绑包 流程 使用以下命令, 定义包含证书颁发机构的 OpenShift Container Platform ConfigMap 证书颁发机构必须存储在 ConfigMap 对象的 ca.crt 键中 $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config 6.4.5. 基本身份验证 CR 示例 以下自定义资源 (CR) 显示基本身份验证身份提供程序的参数和可接受值 基本身份验证 CR apiversion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityproviders: - name: basicidp 1 mappingmethod: claim 2 type: BasicAuth 36

第 6 章配置身份提供程序 basicauth: url: https://www.example.com/remote-idp 3 ca: 4 name: ca-config-map tlsclientcert: 5 name: client-cert-secret tlsclientkey: 6 name: client-key-secret 1 2 3 4 5 6 此提供程序名称作为前缀放在返回的用户 ID 前, 以此组成身份名称 控制如何在此提供程序的身份和 User 对象之间建立映射 接受基本身份验证标头中凭证的 URL 可选 : 对包含 PEM 编码证书颁发机构捆绑包的 OpenShift Container Platform ConfigMap 的引用, 以用于验证所配置 URL 的服务器证书 可选 : 对包含客户端证书的 OpenShift Container Platform Secret 对象的引用, 该证书在向所配置的 URL 发出请求时出示 对包含客户端证书密钥的 OpenShift Container Platform Secret 对象的引用 指定了 tlsclientcert 时必需此项 其他资源 有关适用于所有身份供应商的参数 ( 如 mappingmethod) 信息, 请参阅身份供应商参数 6.4.6. 将身份提供程序添加到集群中 安装集群之后, 请在其中添加一个身份提供程序, 以便您的用户可以进行身份验证 先决条件 创建 OpenShift Container Platform 集群 为身份提供程序创建自定义资源 (CR) 必须已经以管理员身份登录 流程 1. 应用定义的 CR: $ oc apply -f </path/to/cr> 注意 如果一个 CR 不存在,oc apply 会创建一个新的 CR, 并可能会触发以下警告 Warning: oc apply should be used on resources created by either oc create --save-config or oc apply 在这种情况下, 您可以忽略这个警告 2. 以来自身份提供程序的用户身份登录集群, 并在提示时输入密码 37

OpenShift Container Platform 4.7 认证和授和授权 $ oc login -u <username> 3. 确认用户登录成功, 并显示用户名 $ oc whoami 6.4.7. 基本身份供应商的 Apache HTTPD 配置示例 OpenShift Container Platform 4 中的基本身份供应商 (IDP) 配置要求 IDP 服务器的 JSON 响应以获得成功和失败 您可以使用 Apache HTTPD 中的 CGI 脚本来达到此目的 本节提供示例 /etc/httpd/conf.d/login.conf 示例 <VirtualHost *:443> # CGI Scripts in here DocumentRoot /var/www/cgi-bin # SSL Directives SSLEngine on SSLCipherSuite PROFILE=SYSTEM SSLProxyCipherSuite PROFILE=SYSTEM SSLCertificateFile /etc/pki/tls/certs/localhost.crt SSLCertificateKeyFile /etc/pki/tls/private/localhost.key # Configure HTTPD to execute scripts ScriptAlias /basic /var/www/cgi-bin # Handles a failed login attempt ErrorDocument 401 /basic/fail.cgi # Handles authentication <Location /basic/login.cgi> AuthType Basic AuthName "Please Log In" AuthBasicProvider file AuthUserFile /etc/httpd/conf/passwords Require valid-user </Location> </VirtualHost> /var/www/cgi-bin/login.cgi 示例 #!/bin/bash echo "Content-Type: application/json" echo "" echo '{"sub":"userid", "name":"'$remote_user'"}' exit 0 /var/www/cgi-bin/fail.cgi 示例 #!/bin/bash echo "Content-Type: application/json" echo "" 38

第 6 章配置身份提供程序 echo '{"error": "Login failure"}' exit 0 6.4.7.1. 文件要求 以下是您在 Apache HTTPD Web 服务器中创建的文件要求 : login.cgi 和 fail.cgi 必须可执行 (chmod +x) 如果启用了 SELinux,login.cgi 和 fail.cgi 需要有适当的 SELinux 上下文 :restorecon -RFv /var/www/cgi-bin, 或确保上下文是 httpd_sys_script_exec_t( 运行 ls -laz) login.cgi 只有在用户根据 Require and Auth 项成功登陆时才执行 如果用户无法登录, 则执行 fail.cgi, 并做出 HTTP 401 响应 6.4.8. 基本身份验证故障排除 最常见的问题与后端服务器网络连接相关 要进行简单调试, 请在 master 上运行 curl 命令 要测试成功的登录, 请将以下示例命令中的 <user> 和 <password> 替换为有效的凭证 要测试无效的登录, 请将它们替换为错误的凭证 $ curl --cacert /path/to/ca.crt --cert /path/to/client.crt --key /path/to/client.key -u <user>:<password> -v https://www.example.com/remote-idp 成功响应 200 状态并带有 sub(subject) 键则表示成功 : {"sub":"userid"} subject 必须是经过身份验证的用户所特有的, 而且必须不可修改 成功响应可以有选择地提供附加数据, 例如 : 使用 name 键的显示名称 : {"sub":"userid", "name": "User Name",...} 使用 email 键的电子邮件地址 : {"sub":"userid", "email":"user@example.com",...} 失败的响应 使用 preferred_username 键的首选用户名 : {"sub":"014fbff9a07c", "preferred_username":"bob",...} preferred_username 键可用在唯一不可改主体是数据库密钥或 UID 且存在更易读名称的情形中 为经过身份验证的身份置备 OpenShift Container Platform 用户时, 这可用作提示 401 响应表示身份验证失败 39

OpenShift Container Platform 4.7 认证和授和授权 非 200 状态或带有非空 error 键表示错误 :{"error":"error message"} 6.5. 配置请求标头身份提供程序 配置 request-header 身份提供程序, 标识请求标头值中的用户, 例如 X-Remote-User 它通常与设定请求标头值的身份验证代理一起使用 6.5.1. 关于 OpenShift Container Platform 中的身份提供程序 默认情况下, 集群中只有 kubeadmin 用户 要指定身份提供程序, 您必须创建一个自定义资源 (CR) 来描述该身份提供程序并把它添加到集群中 注意 OpenShift Container Platform 用户名不能包括 / : 和 % 6.5.2. 关于请求标头身份验证 请求标头身份提供程序从请求标头值标识用户, 例如 X-Remote-User 它通常与设定请求标头值的身份验证代理一起使用 注意 您还可以将请求标头身份提供程序用于高级配置, 如由社区支持的 SAML 身份验证 请注意, 红帽不支持这个解决方案 用户使用此身份提供程序进行身份验证时, 必须通过身份验证代理访问 https://<namespace_route>/oauth/authorize( 及子路径 ) 要实现此目标, 请将 OAuth 服务器配置为把 OAuth 令牌的未经身份验证的请求重定向到代理到 https://<namespace_route>/oauth/authorize 的代理端点 重定向来自希望基于浏览器型登录流的客户端的未经身份验证请求 : 将 provider.loginurl 参数设为身份验证代理 URL, 该代理将验证交互式客户端并将其请求代理到 https://<namespace_route>/oauth/authorize 重定向来自希望 WWW-Authenticate 质询的客户端的未经身份验证请求 : 将 provider.challengeurl 参数设置为身份验证代理 URL, 该代理将验证希望 WWW- Authenticate 质询的客户端并将其请求代理到 https://<namespace_route>/oauth/authorize provider.challengeurl 和 provider.loginurl 参数可以在 URL 的查询部分中包含以下令牌 : ${url} 替换为当前的 URL, 进行转义以在查询参数中安全使用 例如 :https://www.example.com/sso-login?then=${url} ${query} 替换为当前的查询字符串, 不进行转义 例如 :https://www.example.com/auth-proxy/oauth/authorize?${query} 重要 自 OpenShift Container Platform 4.1 起, 代理必须支持 mutual TLS 40

第 6 章配置身份提供程序 6.5.2.1. Microsoft Windows 上的 SSPI 连接支持 重要 使用 Microsoft Windows 上的 SSPI 连接支持是技术预览功能 技术预览功能不包括在红帽生产服务级别协议 (SLA) 中, 且其功能可能并不完善 因此, 红帽不建议在生产环境中使用它们 这些技术预览功能可以使用户提早试用新的功能, 并有机会在开发阶段提供反馈意见 如需红帽技术预览功能支持范围的更多信息, 请参阅 https://access.redhat.com/support/offerings/techpreview/ OpenShift CLI (oc) 支持安全支持提供程序接口 (SSPI), 以允许 Microsft Windows 上的 SSO 流 如果您使用请求标头身份提供程序与支持 GSSAPI 的代理将 Active Directory 服务器连接到 OpenShift Container Platform, 用户可以通过加入了域的 Microsoft Windows 计算机使用 oc 命令行界面来自动进行 OpenShift Container Platform 身份验证 6.5.3. 创建配置映射 身份提供程序使用 openshift-config 命名空间中的 OpenShift Container Platform ConfigMap 对象来包含证书颁发机构捆绑包 主要用于包含身份提供程序所需的证书捆绑包 流程 使用以下命令, 定义包含证书颁发机构的 OpenShift Container Platform ConfigMap 证书颁发机构必须存储在 ConfigMap 对象的 ca.crt 键中 $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config 6.5.4. 请求标头 CR 示例 以下自定义资源 (CR) 显示请求标头身份提供程序的参数和可接受值 请求标题 CR apiversion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityproviders: - name: requestheaderidp 1 mappingmethod: claim 2 type: RequestHeader requestheader: challengeurl: "https://www.example.com/challenging-proxy/oauth/authorize?${query}" 3 loginurl: "https://www.example.com/login-proxy/oauth/authorize?${query}" 4 ca: 5 name: ca-config-map clientcommonnames: 6 - my-auth-proxy headers: 7 - X-Remote-User 41

OpenShift Container Platform 4.7 认证和授和授权 - SSO-User emailheaders: 8 - X-Remote-User-Email nameheaders: 9 - X-Remote-User-Display-Name preferredusernameheaders: 10 - X-Remote-User-Login 1 2 3 4 5 此提供程序名称作为前缀放在请求标头中的用户名前, 以此组成身份名称 控制如何在此提供程序的身份和 User 对象之间建立映射 可选 : 将未经身份验证的 /oauth/authorize 请求重定向到的 URL, 它将身份验证基于浏览器的客户端并将其请求代理到 https://<namespace_route>/oauth/authorize 代理到 https://<namespace_route>/oauth/authorize 的 URL 必须以 /authorize 结尾 ( 不含尾部斜杠 ), 以及代理子路径, 以便 OAuth 批准流可以正常工作 ${url} 替换为当前的 URL, 进行转义以在查询参数中安全使用 把 ${query} 替换为当前的查询字符串 如果未定义此属性, 则必须使用 loginurl 可选 : 将未经身份验证的 /oauth/authorize 请求重定向到的 URL, 它将身份验证期望 WWW- Authenticate challenges 的客户端, 然后将它们代理到 https://<namespace_route>/oauth/authorize ${url} 替换为当前的 URL, 进行转义以在查询参数中安全使用 把 ${query} 替换为当前的查询字符串 如果未定义此属性, 则必须使用 challengeurl 对包含 PEM 编码证书捆绑包的 OpenShift Container Platform ConfigMap 的引用 用作信任定位符, 以验证远程服务器出示的 TLS 证书 重要 自 OpenShift Container Platform 4.1 起, 此身份提供程序需要 ca 字段 这意味着您的代理必须支持 mutual TLS 6 7 8 9 10 可选 : 通用名称 (cn) 的列表 如果设定, 则必须出示带有指定列表中通用名称 (cn) 的有效客户端证书, 然后才能检查请求标头中的用户名 如果为空, 则允许任何通用名称 只能与 ca 结合使用 按顺序查找用户身份的标头名称 第一个包含值的标头被用作身份 必需, 不区分大小写 按顺序查找电子邮件地址的标头名称 第一个包含值的标头被用作电子邮件地址 可选, 不区分大小写 按顺序查找显示名称的标头名称 第一个包含值的标头被用作显示名称 可选, 不区分大小写 按顺序查找首选用户名的标头名称 ( 如果与通过 headers 中指定的标头确定的不可变身份不同 ) 在置备时, 第一个包含值的标头用作首选用户名 可选, 不区分大小写 其他资源 有关适用于所有身份供应商的参数 ( 如 mappingmethod) 信息, 请参阅身份供应商参数 6.5.5. 将身份提供程序添加到集群中 安装集群之后, 请在其中添加一个身份提供程序, 以便您的用户可以进行身份验证 42

第 6 章配置身份提供程序 先决条件 创建 OpenShift Container Platform 集群 为身份提供程序创建自定义资源 (CR) 必须已经以管理员身份登录 流程 1. 应用定义的 CR: $ oc apply -f </path/to/cr> 注意 如果一个 CR 不存在,oc apply 会创建一个新的 CR, 并可能会触发以下警告 Warning: oc apply should be used on resources created by either oc create --save-config or oc apply 在这种情况下, 您可以忽略这个警告 2. 以来自身份提供程序的用户身份登录集群, 并在提示时输入密码 $ oc login -u <username> 3. 确认用户登录成功, 并显示用户名 $ oc whoami 6.5.6. 使用请求标头进行 Apache 验证的配置示例 本例使用请求标头身份提供程序为 OpenShift Container Platform 配置 Apache 验证代理服务器 自定义代理配置使用 mod_auth_gssapi 模块是使用请求标头身份提供程序配置 Apache 认证代理的流行方法, 但这并不是必需的 如果满足以下要求, 您可以轻松地使用其他代理 : 阻断来自客户端请求的 X-Remote-User 标头以防止欺骗 在 RequestHeaderIdentityProvider 配置中强制进行客户端证书验证 使用质询流来要求 X-CSRF-Token 标头为所有身份验证请求设置 请确定只有 /oauth/authorize 端点和其子路径通过代理处理 重定向必须被重写, 以便后端服务器可以将客户端发送到正确的位置 代理到 https://<namespace_route>/oauth/authorize 的 URL 必须以 /authorize 结尾, 且最后没有尾部斜杠 例如 : https://proxy.example.com/login-proxy/authorize? 必须代理到 https://<namespace_route>/oauth/authorize? 代理到 https://<namespace_route>/oauth/authorize 的 URL 的子路径必须代理至 https://<namespace_route>/oauth/authorize 的子路径 例如 : https://proxy.example.com/login-proxy/authorize/approve? 必须代理到 https://<namespace_route>/oauth/authorize/approve? 43

OpenShift Container Platform 4.7 认证和授和授权 注意 https://<namespace_route> 地址是到 OAuth 服务器的路由, 可通过运行 oc get route - n openshift-authentication 获取 使用请求标头标头配置 Apache 身份验证这个示例使用 mod_auth_gssapi 模块使用请求标头身份提供程序配置 Apache 验证代理 先决条件 流程 通过 Optional channel 获得 mod_auth_gssapi 模块 您必须在本地机器中安装以下软件包 : httpd mod_ssl mod_session apr-util-openssl mod_auth_gssapi 生成用于验证提交可信标头的请求的 CA 定义包含 CA 的 OpenShift Container Platform ConfigMap 对象 这可以通过运行以下命令完成 : $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config 证书颁发机构必须存储在 ConfigMap 的 ca.crt 键中 示例 : 为代理生成客户端证书您可以使用任何 x509 证书工具生成这个证书 客户端证书必须由您生成的 CA 签名, 以验证提交可信标头的请求 为身份提供程序创建自定义资源 (CR) 此代理使用客户端证书连接到 OAuth 服务器, 该服务器被配置为信任 X-Remote-User 标头 1. 为 Apache 配置创建证书 您通过 SSLProxyMachineCertificateFile 参数值指定的证书是服务器验证代理时使用的代理客户端的证书 它必须使用 TLS Web 客户端身份端身份验证验证作为扩展密钥类型 2. 创建 Apache 配置文件 使用以下模板来提供所需设置和值 : 重要 仔细检查模板的内容, 并根据您的环境自定义其相应的内容 LoadModule request_module modules/mod_request.so LoadModule auth_gssapi_module modules/mod_auth_gssapi.so # Some Apache configurations might require these modules. # LoadModule auth_form_module modules/mod_auth_form.so # LoadModule session_module modules/mod_session.so # Nothing needs to be served over HTTP. This virtual host simply redirects to 44

第 6 章配置身份提供程序 # HTTPS. <VirtualHost *:80> DocumentRoot /var/www/html RewriteEngine On RewriteRule ^(.*)$ https://%{http_host}$1 [R,L] </VirtualHost> <VirtualHost *:443> # This needs to match the certificates you generated. See the CN and X509v3 # Subject Alternative Name in the output of: # openssl x509 -text -in /etc/pki/tls/certs/localhost.crt ServerName www.example.com DocumentRoot /var/www/html SSLEngine on SSLCertificateFile /etc/pki/tls/certs/localhost.crt SSLCertificateKeyFile /etc/pki/tls/private/localhost.key SSLCACertificateFile /etc/pki/ca/certs/ca.crt SSLProxyEngine on SSLProxyCACertificateFile /etc/pki/ca/certs/ca.crt # It is critical to enforce client certificates. Otherwise, requests can # spoof the X-Remote-User header by accessing the /oauth/authorize endpoint # directly. SSLProxyMachineCertificateFile /etc/pki/tls/certs/authproxy.pem # To use the challenging-proxy, an X-Csrf-Token must be present. RewriteCond %{REQUEST_URI} ^/challenging-proxy RewriteCond %{HTTP:X-Csrf-Token} ^$ [NC] RewriteRule ^.* - [F,L] <Location /challenging-proxy/oauth/authorize> # Insert your backend server name/ip here. ProxyPass https://<namespace_route>/oauth/authorize AuthName "SSO Login" # For Kerberos AuthType GSSAPI Require valid-user RequestHeader set X-Remote-User %{REMOTE_USER}s GssapiCredStore keytab:/etc/httpd/protected/auth-proxy.keytab # Enable the following if you want to allow users to fallback # to password based authentication when they do not have a client # configured to perform kerberos authentication. GssapiBasicAuth On # For ldap: # AuthBasicProvider ldap # AuthLDAPURL "ldap://ldap.example.com:389/ou=people,dc=my-domain,dc=com?uid? sub?(objectclass=*)" </Location> <Location /login-proxy/oauth/authorize> # Insert your backend server name/ip here. ProxyPass https://<namespace_route>/oauth/authorize 45

OpenShift Container Platform 4.7 认证和授和授权 AuthName "SSO Login" AuthType GSSAPI Require valid-user RequestHeader set X-Remote-User %{REMOTE_USER}s env=remote_user GssapiCredStore keytab:/etc/httpd/protected/auth-proxy.keytab # Enable the following if you want to allow users to fallback # to password based authentication when they do not have a client # configured to perform kerberos authentication. GssapiBasicAuth On ErrorDocument 401 /login.html </Location> </VirtualHost> RequestHeader unset X-Remote-User 注意 https://<namespace_route> 地址是到 OAuth 服务器的路由, 可通过运行 oc get route -n openshift-authentication 获取 3. 更新自定义资源 (CR) 中的 identityproviders 小节 : identityproviders: - name: requestheaderidp type: RequestHeader requestheader: challengeurl: "https://<namespace_route>/challenging-proxy/oauth/authorize?${query}" loginurl: "https://<namespace_route>/login-proxy/oauth/authorize?${query}" ca: name: ca-config-map clientcommonnames: - my-auth-proxy headers: - X-Remote-User 4. 验证配置 : a. 通过提供正确的客户端证书和标头, 确认您可以通过请求令牌来绕过代理 : # curl -L -k -H "X-Remote-User: joe" \ --cert /etc/pki/tls/certs/authproxy.pem \ https://<namespace_route>/oauth/token/request b. 通过在没有证书的情况下请求令牌, 确认没有提供客户端证书的请求会失败 : # curl -L -k -H "X-Remote-User: joe" \ https://<namespace_route>/oauth/token/request c. 确认 challengeurl 重定向已启用 : 46

第 6 章配置身份提供程序 # curl -k -v -H 'X-Csrf-Token: 1' \ https://<namespace_route>/oauth/authorize?client_id=openshift-challengingclient&response_type=token 复制 challengeurl 重定向, 以用于下一步骤 d. 运行这个命令会显示一个带有 WWW-Authenticate 基本质询, 协商质询或两个质询都有的 401 响应 : # curl -k -v -H 'X-Csrf-Token: 1' \ <challengeurl_redirect + query> e. 测试在使用 Kerberos ticket 和不使用 Kerberos ticket 的情况下登录到 OpenShift CLI(oc): i. 如果您使用 kinit 生成了 Kerberos ticket, 请将其销毁 : # kdestroy -c cache_name 1 1 请确定提供 Kerberos 缓存的名称 ii. 使用您的 Kerberos 凭证登录到 oc: # oc login -u <username> 在提示符后输入您的 Kerberos 密码 iii. 注销 oc 工具 : # oc logout iv. 使用您的 Kerberos 凭证获得一个 ticket: # kinit 在提示符后输入您的 Kerberos 用户名和密码 v. 确认您可以登录到 oc: # oc login 如果配置正确, 您会在不需要单独输入凭证的情况下成功登录 6.6. 配置 GITHUB 或 GITHUB ENTERPRISE 身份提供程序 配置 github 身份提供程序, 针对 GitHub 或 GitHub Enterprise 的 OAuth 身份验证服务器验证用户名和密码 OAuth 可以协助 OpenShift Container Platform 和 GitHub 或 GitHub Enterprise 之间的令牌交换流 您可以使用 GitHub 集成来连接 GitHub 或 GitHub Enterprise 对于 GitHub Enterprise 集成, 您必须提供实例的 hostname, 并可选择提供要在服务器请求中使用的 ca 证书捆绑包 47

OpenShift Container Platform 4.7 认证和授和授权 注意 除非有所注明, 否则以下步骤同时适用于 GitHub 和 GitHub Enterprise 配置 GitHub 身份验证后, 用户可使用 GitHub 凭证登录 OpenShift Container Platform 为防止具有任何 GitHub 用户 ID 的任何人登录 OpenShift Container Platform 集群, 您可以将访问权利限制给仅属于特定 GitHub 组织的用户 6.6.1. 关于 OpenShift Container Platform 中的身份提供程序 默认情况下, 集群中只有 kubeadmin 用户 要指定身份提供程序, 您必须创建一个自定义资源 (CR) 来描述该身份提供程序并把它添加到集群中 注意 OpenShift Container Platform 用户名不能包括 / : 和 % 6.6.2. 注册 GitHub 应用程序 要将 GitHub 或 GitHub Enterprise 用作身份提供程序, 您必须注册要使用的应用程序 流程 1. 在 GitHub 上注册应用程序 : 对于 GitHub, 点击 Settings Developer settings OAuth Apps Register a new OAuth application 对于 GitHub Enterprise, 前往 GitHub Enterprise 主页, 然后点击 Settings Developer settings Register a new application 2. 输入应用程序名称, 如 My OpenShift Install 3. 输入主页 URL, 如 https://oauth-openshift.apps.<cluster-name>.<cluster-domain> 4. 可选 : 输入应用程序描述 5. 输入授权回调 URL, 其中 URL 末尾包含身份提供程序 name: https://oauth-openshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-providername> 例如 : https://oauth-openshift.apps.example-openshift-cluster.com/oauth2callback/github/ 6. 点击 Register application GitHub 提供客户端 ID 和客户端 secret 您需要使用这些值来完成身份提供程序配置 6.6.3. 创建 secret 身份提供程序使用 openshift-config 命名空间中的 OpenShift Container Platform Secret 对象来包含客户端 secret 客户端证书和密钥 48

第 6 章配置身份提供程序 您可以使用以下命令, 定义一个包含字符串的 OpenShift Container Platform Secret 对象 $ oc create secret generic <secret_name> --from-literal=clientsecret=<secret> -n openshiftconfig 您可以使用以下命令, 定义一个文件 ( 如证书文件 ) 内容的 OpenShift Container Platform Secret $ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config 6.6.4. 创建配置映射 身份提供程序使用 openshift-config 命名空间中的 OpenShift Container Platform ConfigMap 对象来包含证书颁发机构捆绑包 主要用于包含身份提供程序所需的证书捆绑包 注意 只有 GitHub Enterprise 需要此步骤 流程 使用以下命令, 定义包含证书颁发机构的 OpenShift Container Platform ConfigMap 证书颁发机构必须存储在 ConfigMap 对象的 ca.crt 键中 $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config 6.6.5. GitHub CR 示例 以下自定义资源 (CR) 显示 GitHub 身份提供程序的参数和可接受值 GitHub CR apiversion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityproviders: - name: githubidp 1 mappingmethod: claim 2 type: GitHub github: ca: 3 name: ca-config-map clientid: {...} 4 clientsecret: 5 name: github-secret hostname:... 6 organizations: 7 - myorganization1 - myorganization2 49

OpenShift Container Platform 4.7 认证和授和授权 teams: 8 - myorganization1/team-a - myorganization2/team-b 1 2 3 4 5 6 7 8 此提供程序名称作为前缀放在 GitHub 数字用户 ID 前, 以此组成身份名称 它还可用来构建回调 URL 控制如何在此提供程序的身份和 User 对象之间建立映射 可选 : 对包含 PEM 编码证书颁发机构捆绑包的 OpenShift Container Platform ConfigMap 的引用, 以用于验证所配置 URL 的服务器证书 仅用于带有非公开信任的根证书的 GitHub Enterprise 注册的 GitHub OAuth 应用程序的客户端 ID 应用程序必须配置有回调 URL https://oauthopenshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name> 对包含 GitHub 发布的客户端 Secret 的 OpenShift Container Platform Secret 的引用 对于 GitHub Enterprise, 您必须提供实例的主机名, 如 example.com 这个值必须与 /setup/settings 文件中的 GitHub Enterprise hostname 值匹配, 且不可包括端口号 如果未设定这个值, 则必须定义 teams 或 organizations 对于 GitHub, 请省略此参数 组织列表 必须设置 organizations 或 teams 字段, 除非设置 hostname 字段, 或者将 mappingmethod 设为 lookup 不可与 teams 字段结合使用 团队列表 必须设置 teams 或 organizations 字段, 除非设置 hostname 字段, 或者将 mappingmethod 设为 lookup 不可与 organizations 字段结合使用 注意 如果指定了 organizations 或 teams, 只有至少是一个所列组织成员的 GitHub 用户才能登录 如果在 clientid 中配置的 GitHub OAuth 应用程序不归该组织所有, 则组织所有者必须授予第三方访问权限才能使用此选项 这可以在组织管理员第一次登录 GitHub 时完成, 也可以在 GitHub 组织设置中完成 其他资源 有关适用于所有身份供应商的参数 ( 如 mappingmethod) 信息, 请参阅身份供应商参数 6.6.6. 将身份提供程序添加到集群中 安装集群之后, 请在其中添加一个身份提供程序, 以便您的用户可以进行身份验证 先决条件 创建 OpenShift Container Platform 集群 为身份提供程序创建自定义资源 (CR) 必须已经以管理员身份登录 流程 1. 应用定义的 CR: 50

第 6 章配置身份提供程序 $ oc apply -f </path/to/cr> 注意 如果一个 CR 不存在,oc apply 会创建一个新的 CR, 并可能会触发以下警告 Warning: oc apply should be used on resources created by either oc create --save-config or oc apply 在这种情况下, 您可以忽略这个警告 2. 从 OAuth 服务器获取令牌 只要 kubeadmin 用户已被删除,oc login 命令就会提供如何访问可以获得令牌的网页的说明 您还可以通过使用 web 控制台的 (?) 访问此页面 Help Command Line Tools Copy Login Command. 3. 登录到集群, 提供令牌进行身份验证 $ oc login --token=<token> 注意 这个身份提供程序不支持使用用户名和密码登录 4. 确认用户登录成功, 并显示用户名 $ oc whoami 6.7. 配置 GITLAB 身份提供程序 配置 gitlab 身份提供程序, 使用 GitLab.com 或任何其他 GitLab 实例作为身份提供程序 如果使用 GitLab 版本 7.7.0 到 11.0, 您可以使用 OAuth 集成进行连接 如果使用 GitLab 版本 11.1 或更高版本, 您可以使用 OpenID Connect (OIDC) 进行连接, 而不使用 OAuth 6.7.1. 关于 OpenShift Container Platform 中的身份提供程序 默认情况下, 集群中只有 kubeadmin 用户 要指定身份提供程序, 您必须创建一个自定义资源 (CR) 来描述该身份提供程序并把它添加到集群中 注意 OpenShift Container Platform 用户名不能包括 / : 和 % 6.7.2. 创建 secret 身份提供程序使用 openshift-config 命名空间中的 OpenShift Container Platform Secret 对象来包含客户端 secret 客户端证书和密钥 您可以使用以下命令, 定义一个包含字符串的 OpenShift Container Platform Secret 对象 $ oc create secret generic <secret_name> --from-literal=clientsecret=<secret> -n openshiftconfig 51

OpenShift Container Platform 4.7 认证和授和授权 您可以使用以下命令, 定义一个文件 ( 如证书文件 ) 内容的 OpenShift Container Platform Secret $ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config 6.7.3. 创建配置映射 身份提供程序使用 openshift-config 命名空间中的 OpenShift Container Platform ConfigMap 对象来包含证书颁发机构捆绑包 主要用于包含身份提供程序所需的证书捆绑包 注意 只有 GitHub Enterprise 需要此步骤 流程 使用以下命令, 定义包含证书颁发机构的 OpenShift Container Platform ConfigMap 证书颁发机构必须存储在 ConfigMap 对象的 ca.crt 键中 $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config 6.7.4. GitLab CR 示例 以下自定义资源 (CR) 显示 GitLab 身份提供程序的参数和可接受值 GitLab CR apiversion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityproviders: - name: gitlabidp 1 mappingmethod: claim 2 type: GitLab gitlab: clientid: {...} 3 clientsecret: 4 name: gitlab-secret url: https://gitlab.com 5 ca: 6 name: ca-config-map 1 2 3 此提供程序名称作为前缀放在 GitLab 数字用户 ID 前, 以此组成身份名称 它还可用来构建回调 URL 控制如何在此提供程序的身份和 User 对象之间建立映射 注册的 GitLab OAuth 应用程序的客户端 ID 应用程序必须配置有回调 URL https://oauthopenshift.apps.<cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name> 52

第 6 章配置身份提供程序 4 5 6 对包含 GitLab 发布的客户端 Secret 的 OpenShift Container Platform Secret 的引用 GitLab 提供程序的主机 URL 这可以是 https://gitlab.com/ 或其他自托管 GitLab 实例 可选 : 对包含 PEM 编码证书颁发机构捆绑包的 OpenShift Container Platform ConfigMap 的引用, 以用于验证所配置 URL 的服务器证书 其他资源 有关适用于所有身份供应商的参数 ( 如 mappingmethod) 信息, 请参阅身份供应商参数 6.7.5. 将身份提供程序添加到集群中 安装集群之后, 请在其中添加一个身份提供程序, 以便您的用户可以进行身份验证 先决条件 创建 OpenShift Container Platform 集群 为身份提供程序创建自定义资源 (CR) 必须已经以管理员身份登录 流程 1. 应用定义的 CR: $ oc apply -f </path/to/cr> 注意 如果一个 CR 不存在,oc apply 会创建一个新的 CR, 并可能会触发以下警告 Warning: oc apply should be used on resources created by either oc create --save-config or oc apply 在这种情况下, 您可以忽略这个警告 2. 以来自身份提供程序的用户身份登录集群, 并在提示时输入密码 $ oc login -u <username> 3. 确认用户登录成功, 并显示用户名 $ oc whoami 6.8. 配置 GOOGLE 身份提供程序 配置 google 身份提供程序, 使用 Google 的 OpenID Connect 集成 注意 使用 Google 作为身份提供程序要求用户使用 <master>/oauth/token/request 来获取令牌, 以便用于命令行工具 53

OpenShift Container Platform 4.7 认证和授和授权 警告 使用 Google 作为身份提供程序时, 任何 Google 用户都能与您的服务器进行身份验证 您可以使用 hosteddomain 配置属性, 将身份验证限制为特定托管域的成员 6.8.1. 关于 OpenShift Container Platform 中的身份提供程序 默认情况下, 集群中只有 kubeadmin 用户 要指定身份提供程序, 您必须创建一个自定义资源 (CR) 来描述该身份提供程序并把它添加到集群中 注意 OpenShift Container Platform 用户名不能包括 / : 和 % 6.8.2. 创建 secret 身份提供程序使用 openshift-config 命名空间中的 OpenShift Container Platform Secret 对象来包含客户端 secret 客户端证书和密钥 您可以使用以下命令, 定义一个包含字符串的 OpenShift Container Platform Secret 对象 $ oc create secret generic <secret_name> --from-literal=clientsecret=<secret> -n openshiftconfig 您可以使用以下命令, 定义一个文件 ( 如证书文件 ) 内容的 OpenShift Container Platform Secret $ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config 6.8.3. Google CR 示例 以下自定义资源 (CR) 显示 Google 身份提供程序的参数和可接受值 Google CR apiversion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityproviders: - name: googleidp 1 mappingmethod: claim 2 type: Google google: clientid: {...} 3 clientsecret: 4 name: google-secret hosteddomain: "example.com" 5 54

第 6 章配置身份提供程序 1 2 3 4 5 此提供程序名称作为前缀放在 Google 数字用户 ID 前, 以此组成身份名称 它还可用来构建的重定向 URL 控制如何在此提供程序的身份和 User 对象之间建立映射 注册的 Google 项目的客户端 ID 项目必须配置有重定向 URI https://oauth-openshift.apps. <cluster-name>.<cluster-domain>/oauth2callback/<idp-provider-name> 对包含 Google 发布的客户端 Secret 的 OpenShift Container Platform Secret 的引用 用于限制登录帐户的托管域 如果使用了 lookup mappingmethod, 则可选 如果为空, 任何 Google 帐户都可进行身份验证 其他资源 有关适用于所有身份供应商的参数 ( 如 mappingmethod) 信息, 请参阅身份供应商参数 6.8.4. 将身份提供程序添加到集群中 安装集群之后, 请在其中添加一个身份提供程序, 以便您的用户可以进行身份验证 先决条件 创建 OpenShift Container Platform 集群 为身份提供程序创建自定义资源 (CR) 必须已经以管理员身份登录 流程 1. 应用定义的 CR: $ oc apply -f </path/to/cr> 注意 如果一个 CR 不存在,oc apply 会创建一个新的 CR, 并可能会触发以下警告 Warning: oc apply should be used on resources created by either oc create --save-config or oc apply 在这种情况下, 您可以忽略这个警告 2. 从 OAuth 服务器获取令牌 只要 kubeadmin 用户已被删除,oc login 命令就会提供如何访问可以获得令牌的网页的说明 您还可以通过使用 web 控制台的 (?) 访问此页面 Help Command Line Tools Copy Login Command. 3. 登录到集群, 提供令牌进行身份验证 $ oc login --token=<token> 55

OpenShift Container Platform 4.7 认证和授和授权 注意 这个身份提供程序不支持使用用户名和密码登录 4. 确认用户登录成功, 并显示用户名 $ oc whoami 6.9. 配置 OPENID CONNECT 身份提供程序 配置 oidc 身份提供程序, 使用授权代码流与 OpenID Connect 身份提供程序集成 您可以将 Red Hat Single Sign-On 配置为 OpenShift Container Platform 的 OpenID Connect 身份提供程序 重要 OpenShift Container Platform 中的 Authentication Operator 要求配置的 OpenID Connect 身份提供程序实现 OpenID Connect Discovery 规格 注意 不支持 ID Token 和 UserInfo 解密 默认情况下, 需要 openid 范围 如果必要, 可在 extrascopes 字段中指定额外的范围 声明可读取自从 OpenID 身份提供程序返回的 JWT id_token; 若有指定, 也可读取自从 UserInfo URL 返回的 JSON 必须至少配置一个声明, 以用作用户的身份 标准的身份声明是 sub 您还可以指定将哪些声明用作用户的首选用户名 显示名称和电子邮件地址 如果指定了多个声明, 则使用第一个带有非空值的声明 标准的声明是 : 声明 描述 sub subject identifier 的缩写 用户在签发者处的远程身份 preferred_username 置备用户时的首选用户名 用户希望使用的简写名称, 如 janedoe 通常, 与身份验证系统中用户的登录或用户名对应的值, 如用户名或电子邮件 email 电子邮件地址 name 显示名称 如需更多信息, 请参阅 OpenID 声明文档 56

第 6 章配置身份提供程序 注意 使用 OpenID Connect 身份提供程序要求用户使用 <master>/oauth/token/request 来获取令牌, 以便用于命令行工具 6.9.1. 关于 OpenShift Container Platform 中的身份提供程序 默认情况下, 集群中只有 kubeadmin 用户 要指定身份提供程序, 您必须创建一个自定义资源 (CR) 来描述该身份提供程序并把它添加到集群中 注意 OpenShift Container Platform 用户名不能包括 / : 和 % 6.9.2. 创建 secret 身份提供程序使用 openshift-config 命名空间中的 OpenShift Container Platform Secret 对象来包含客户端 secret 客户端证书和密钥 您可以使用以下命令, 定义一个包含字符串的 OpenShift Container Platform Secret 对象 $ oc create secret generic <secret_name> --from-literal=clientsecret=<secret> -n openshiftconfig 您可以使用以下命令, 定义一个文件 ( 如证书文件 ) 内容的 OpenShift Container Platform Secret $ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config 6.9.3. 创建配置映射 身份提供程序使用 openshift-config 命名空间中的 OpenShift Container Platform ConfigMap 对象来包含证书颁发机构捆绑包 主要用于包含身份提供程序所需的证书捆绑包 注意 只有 GitHub Enterprise 需要此步骤 流程 使用以下命令, 定义包含证书颁发机构的 OpenShift Container Platform ConfigMap 证书颁发机构必须存储在 ConfigMap 对象的 ca.crt 键中 $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config 6.9.4. OpenID Connect CR 示例 以下自定义资源 (CR) 显示 OpenID Connect 身份提供程序的参数和可接受值 如果您必须指定自定义证书捆绑包 额外范围 额外授权请求参数或 userinfo URL, 请使用完整的 OpenID Connect CR 标准 OpenID Connect CR 57

OpenShift Container Platform 4.7 认证和授和授权 apiversion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityproviders: - name: oidcidp 1 mappingmethod: claim 2 type: OpenID openid: clientid:... 3 clientsecret: 4 name: idp-secret claims: 5 preferredusername: - preferred_username name: - name email: - email issuer: https://www.idp-issuer.com 6 1 2 3 4 5 6 此提供程序名称作为前缀放在身份声明值前, 以此组成身份名称 它还可用来构建的重定向 URL 控制如何在此提供程序的身份和 User 对象之间建立映射 在 OpenID 提供程序中注册的客户端的客户端 ID 该客户端必须能够重定向到 https://oauthopenshift.apps.<cluster_name>.<cluster_domain>/oauth2callback/<idp_provider_name> 对包含客户端 secret 的 OpenShift Container Platform Secret 对象的引用 用作身份的声明的列表 使用第一个非空声明 至少需要一个声明 如果列出的声明都没有值, 身份验证会失败 例如, 这使用返回的 id_token 中的 sub 声明的值作为用户的身份 OpenID 规范中描述的签发者标识符 必须使用 https, 且不带查询或分段组件 完整 OpenID Connect CR apiversion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityproviders: - name: oidcidp mappingmethod: claim type: OpenID openid: clientid:... clientsecret: name: idp-secret ca: 1 name: ca-config-map extrascopes: 2 58

第 6 章配置身份提供程序 - email - profile extraauthorizeparameters: 3 include_granted_scopes: "true" claims: preferredusername: 4 - preferred_username - email name: 5 - nickname - given_name - name email: 6 - custom_email_claim - email issuer: https://www.idp-issuer.com 1 2 3 4 5 6 可选 : 对包含 PEM 编码证书颁发机构捆绑包的 OpenShift Container Platform 配置映射的引用, 以用于验证所配置 URL 的服务器证书 除 openid 范围外的可选请求范围列表, 在授权令牌请求期间使用 添加至授权令牌请求的附加参数的可选映射 为此身份置备用户时用作首选用户名的声明的列表 使用第一个非空声明 用作显示名称的声明列表 使用第一个非空声明 用作电子邮件地址的声明列表 使用第一个非空声明 其他资源 有关适用于所有身份供应商的参数 ( 如 mappingmethod) 信息, 请参阅身份供应商参数 6.9.5. 将身份提供程序添加到集群中 安装集群之后, 请在其中添加一个身份提供程序, 以便您的用户可以进行身份验证 先决条件 创建 OpenShift Container Platform 集群 为身份提供程序创建自定义资源 (CR) 必须已经以管理员身份登录 流程 1. 应用定义的 CR: $ oc apply -f </path/to/cr> 59

OpenShift Container Platform 4.7 认证和授和授权 注意 如果一个 CR 不存在,oc apply 会创建一个新的 CR, 并可能会触发以下警告 Warning: oc apply should be used on resources created by either oc create --save-config or oc apply 在这种情况下, 您可以忽略这个警告 2. 从 OAuth 服务器获取令牌 只要 kubeadmin 用户已被删除,oc login 命令就会提供如何访问可以获得令牌的网页的说明 您还可以通过使用 web 控制台的 (?) 访问此页面 Help Command Line Tools Copy Login Command. 3. 登录到集群, 提供令牌进行身份验证 $ oc login --token=<token> 注意 如果您的 OpenID Connect 身份提供程序支持资源所有者密码凭证 (ROPC) 授权流, 您可以使用用户名和密码登录 您可能需要执行相应的步骤, 为身份提供程序启用 ROPC 授权流 在 OpenShift Container Platform 中配置 OIDC 身份提供程序后, 您可以使用以下命令登录, 以提示您的用户名和密码 : $ oc login -u <identity_provider_username> --server= <api_server_url_and_port> 4. 确认用户登录成功, 并显示用户名 $ oc whoami 6.9.6. 使用 web 控制台配置身份提供程序 通过 web 控制台而非 CLI 配置身份提供程序 (IDP) 先决条件 您必须以集群管理员身份登录到 web 控制台 流程 1. 导航至 Administration Cluster Settings 2. 在 Global Configuration 选项卡下, 点 OAuth 3. 在 Identity Providers 部分中, 从 Add 下拉菜单中选择您的身份提供程序 注意 您可以通过 web 控制台来指定多个 IDP, 而不会覆盖现有的 IDP 60

第 7 章使用 RBAC 定义和应用权限 第 7 章使用 RBAC 定义和应用权限 7.1. RBAC 概述 基于角色的访问控制 (RBAC) 对象决定是否允许用户在项目内执行给定的操作 集群管理员可以使用集群角色和绑定来控制谁对 OpenShift Container Platform 平台本身和所有项目具有各种访问权限等级 开发人员可以使用本地角色和绑定来控制谁有权访问他们的项目 请注意, 授权是与身份验证分开的一个步骤, 身份验证更在于确定执行操作的人的身份 授权通过使用以下几项来管理 : 授权对权对象 描述 规则一组对象上允许的操作集合 例如, 用户或服务帐户能否创建建 (create) Pod 角色 规则的集合 可以将用户和组关联或绑定到多个角色 绑定 用户和 / 组与角色之间的关联 控制授权的 RBAC 角色和绑定有两个级别 : RBAC 级别 描述 集群 RBAC 对所有项目均适用的角色和绑定 集群角色存在于集群范围, 集群角色绑定只能引用集群角色 本地 RBAC 作用于特定项目的角色和绑定 虽然本地角色只存在于单个项目中, 但本地角色绑定可以同时引用集群和本地角色 集群角色绑定是存在于集群级别的绑定 角色绑定存在于项目级别 集群角色 view 必须使用本地角色绑定来绑定到用户, 以便该用户能够查看项目 只有集群角色不提供特定情形所需的权限集合时才应创建本地角色 这种双级分级结构允许通过集群角色在多个项目间重复使用, 同时允许通过本地角色在个别项目中自定义 在评估过程中, 同时使用集群角色绑定和本地角色绑定 例如 : 1. 选中集群范围的 allow 规则 2. 选中本地绑定的 allow 规则 3. 默认为拒绝 7.1.1. 默认集群角色 61

OpenShift Container Platform 4.7 认证和授和授权 OpenShift Container Platform 包括了一组默认的集群角色, 您可以在集群范围或本地将它们绑定到用户和组 如果需要, 可以手动修改默认集群角色 默认集群角色 描述 admin 项目管理者 如果在本地绑定中使用, 则 admin 有权查看项目中的任何资源, 并且修改项目中除配额外的任何资源 basic-user 此用户可以获取有关项目和用户的基本信息 cluster-admin 此超级用户可以在任意项目中执行任何操作 当使用本地绑定来绑定一个用户时, 这些用户可以完全控制项目中每一资源的配额和所有操作 cluster-status 此用户可以获取基本的集群状态信息 edit 此用户可以修改项目中大多数对象, 但无权查看或修改角色或绑定 self-provisioner 此用户可以创建自己的项目 view 此用户无法进行任何修改, 但可以查看项目中的大多数对象 不能查看或修改角色或绑定 请注意本地和集群绑定之间的区别 例如, 如果使用本地角色绑定将 cluster-admin 角色绑定到一个用户, 这可能看似该用户具有了集群管理员的特权 事实并非如此 将 cluster-admin 绑定到项目里的某一用户, 仅会将该项目的超级管理员特权授予这一用户 该用户具有集群角色 admin 的权限, 以及该项目的一些额外权限, 例如能够编辑项目的速率限制 通过 web 控制台 UI 操作时此绑定可能会令人混淆, 因为它不会列出绑定到真正集群管理员的集群角色绑定 然而, 它会列出可用来本地绑定 cluster-admin 的本地角色绑定 下方展示了集群角色 本地角色 集群角色绑定 本地角色绑定 用户 组和服务帐户之间的关系 62

第 7 章使用 RBAC 定义和应用权限 7.1.2. 评估授权 OpenShift Container Platform 使用以下几项来评估授权 : 身份 操作 用户名以及用户所属组的列表 您执行的操作 在大多数情况下, 这由以下几项组成 : 项目 : 您访问的项目 项目是一种附带额外注解的 Kubernetes 命名空间, 使一个社区的用户可以在与其他社区隔离的前提下组织和管理其内容 操作动词 : 操作本身 :get list create update delete deletecollection 或 watch 资源名称 : 您访问的 API 端点 绑定绑定的完整列表, 用户或组与角色之间的关联 OpenShift Container Platform 通过以下几个步骤评估授权 : 1. 使用身份和项目范围操作来查找应用到用户或所属组的所有绑定 2. 使用绑定来查找应用的所有角色 3. 使用角色来查找应用的所有规则 63