4.4. 配置基本身份验证身份提供程序

配置 basic-authentication 身份提供程序，以便用户使用针对远程身份提供程序验证的凭证来登录 OpenShift Container Platform。基本身份验证是一种通用后端集成机制。

4.4.1. 关于 OpenShift Container Platform 中的身份提供程序

默认情况下，集群中只有 kubeadmin 用户。要指定身份提供程序，您必须创建一个自定义资源 (CR) 来描述该身份提供程序并把它添加到集群中。

注意

OpenShift Container Platform 用户名不能包括 /、: 和 %。

4.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", ...}

使用 email 键的电子邮件地址。例如：

{"sub":"userid", "email":"user@example.com", ...}

使用 preferred_username 键的首选用户名。这可用在唯一不可改主体是数据库密钥或 UID 且存在更易读名称的情形中。为经过身份验证的身份置备 OpenShift Container Platform 用户时，这可用作提示。例如：
```
{"sub":"014fbff9a07c", "preferred_username":"bob", ...}
```

4.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 openshift-config
```
您可以使用以下命令，定义一个文件（如证书文件）内容的 OpenShift Container Platform Secret。
```
$ oc create secret generic <secret_name> --from-file=/path/to/file -n openshift-config
```

4.4.4. 创建 ConfigMap

身份提供程序使用 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
```

4.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
    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: 此提供程序名称作为前缀放在返回的用户 ID 前，以此组成身份名称。
2: 控制如何在此提供程序的身份和用户对象之间建立映射。
3: 接受基本身份验证标头中凭证的 URL。
4: 可选：对包含 PEM 编码证书颁发机构捆绑包的 OpenShift Container Platform ConfigMap 的引用，以用于验证所配置 URL 的服务器证书。
5: 可选：对包含客户端证书的 OpenShift Container Platform Secret 的引用，该证书在向所配置的 URL 发出请求时出示。
6: 对包含客户端证书密钥的 OpenShift Container Platform Secret 的引用。指定了 tlsClientCert 时必需此项。

4.4.6. 将身份提供程序添加到集群中

安装集群之后，请在其中添加一个身份提供程序，以便您的用户可以进行身份验证。

先决条件

创建 OpenShift Container Platform 集群。
为身份提供程序创建自定义资源 (CR)。
必须已经以管理员身份登录。

流程

应用定义的 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。在这种情况下，您可以忽略这个警告。
以来自身份提供程序的用户身份登录集群，并在提示时输入密码。
```
$ oc login -u <username>
```
确认用户登录成功，并显示用户名。
```
$ oc whoami
```

4.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 ""
echo '{"error": "Login failure"}'
exit 0

4.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 响应。

4.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 响应表示身份验证失败。
非 200 状态或带有非空“error”键表示错误：{"error":"Error message"}