OpenShift 文档正在迁移，不久后将仅在 docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

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

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

关于 OpenShift Container Platform 中的身份提供者

默认情况下，集群中只存在kubeadmin用户。要指定身份提供者，必须创建一个描述该身份提供者的自定义资源 (CR)，并将其添加到集群。

OpenShift Container Platform 用户名中包含/、:和%不受支持。

关于基本身份验证

基本身份验证是一种通用的后端集成机制，允许用户使用针对远程身份提供程序验证的凭据登录到 OpenShift Container Platform。

由于基本身份验证是通用的，因此可以将此身份提供程序用于高级身份验证配置。

基本身份验证必须使用到远程服务器的 HTTPS 连接，以防止潜在的用户名和密码窃听以及中间人攻击。

配置基本身份验证后，用户将其用户名和密码发送到 OpenShift Container Platform，然后通过发出服务器到服务器的请求（将凭据作为基本身份验证标头传递）来验证远程服务器上的这些凭据。这要求用户在登录期间将其凭据发送到 OpenShift Container Platform。

这仅适用于用户名/密码登录机制，并且 OpenShift Container Platform 必须能够向远程身份验证服务器发出网络请求。

用户名和密码针对受基本身份验证保护并返回 JSON 的远程 URL 进行验证。

401响应表示身份验证失败。

非200状态或存在非空的“error”键表示错误。

{"error":"Error message"}

带有sub（主题）键的200状态表示成功。

{"sub":"userid"} (1)
1 主题必须对经过身份验证的用户唯一，并且不得修改。

成功的响应可以选择提供其他数据，例如：

  • 使用name键显示名称。例如：

    {"sub":"userid", "name": "User Name", ...}

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

    {"sub":"userid", "email":"[email protected]", ...}

  • 使用preferred_username键的首选用户名。当唯一的、不可更改的主题是数据库键或 UID，并且存在更易于阅读的名称时，这很有用。这在为经过身份验证的身份配置 OpenShift Container Platform 用户时用作提示。例如：

    {"sub":"014fbff9a07c", "preferred_username":"bob", ...}

创建密钥

身份提供者在openshift-config命名空间中使用 OpenShift Container Platform Secret对象来包含客户端密钥、客户端证书和密钥。

步骤

  • 使用以下命令创建一个包含密钥和证书的Secret对象：

    $ oc create secret tls <secret_name> --key=key.pem --cert=cert.pem -n openshift-config

    也可以应用以下YAML来创建密钥

    apiVersion: v1
kind: Secret
metadata:
  name: <secret_name>
  namespace: openshift-config
type: kubernetes.io/tls
data:
  tls.crt: <base64_encoded_cert>
  tls.key: <base64_encoded_key>

创建ConfigMap

身份提供程序使用OpenShift Container Platform ConfigMap对象在openshift-config命名空间中包含证书颁发机构捆绑包。这些主要用于包含身份提供程序所需的证书捆绑包。

步骤

  • 使用以下命令定义包含证书颁发机构的OpenShift Container Platform ConfigMap对象。证书颁发机构必须存储在ConfigMap对象的ca.crt密钥中。

    $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config

    也可以应用以下YAML来创建ConfigMap

    apiVersion: v1
kind: ConfigMap
metadata:
  name: ca-config-map
  namespace: openshift-config
data:
  ca.crt: |
    <CA_certificate_PEM>

基本身份验证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 控制如何在此提供程序的身份和User对象之间建立映射。
3 接受基本身份验证标头中凭据的URL。
4 可选：指向包含PEM编码证书颁发机构捆绑包的OpenShift Container Platform ConfigMap对象的引用，用于验证为配置的URL验证服务器证书。
5 可选：指向包含客户端证书的OpenShift Container Platform Secret对象的引用，在向配置的URL发出请求时出示该证书。
6 指向包含客户端证书密钥的OpenShift Container Platform Secret对象的引用。如果指定了tlsClientCert，则需要此项。
其他资源

  • 有关所有身份提供程序共有的参数（例如mappingMethod）的信息，请参阅身份提供程序参数。

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

安装集群后，向其中添加身份提供程序，以便用户可以进行身份验证。

先决条件

  • 创建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

基本身份提供程序的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

文件要求

这些是在Apache HTTPD Web服务器上创建文件的需求

  • login.cgi和fail.cgi必须是可执行的（chmod +x）。

  • 如果启用了SELinux，则login.cgi和fail.cgi必须具有正确的SELinux上下文：restorecon -RFv /var/www/cgi-bin，或使用ls -laZ确保上下文为httpd_sys_script_exec_t。

  • 只有当用户根据Require and Auth指令成功登录时，才会执行login.cgi。

  • 如果用户登录失败，导致HTTP 401响应，则执行fail.cgi。

基本身份验证故障排除

最常见的问题与后端服务器的网络连接有关。为了简单调试，请在主节点上运行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

成功响应

带有sub（主题）键的200状态表示成功。

{"sub":"userid"}

主题必须对已认证用户唯一，并且不能修改。

成功的响应可以选择提供其他数据，例如：

  • 使用name键显示名称

    {"sub":"userid", "name": "User Name", ...}

  • 使用email键显示电子邮件地址

    {"sub":"userid", "email":"[email protected]", ...}

  • 使用preferred_username键显示首选用户名

    {"sub":"014fbff9a07c", "preferred_username":"bob", ...}

    当唯一的、不可更改的主题是数据库密钥或UID，并且存在更易于阅读的名称时，preferred_username键非常有用。这在为已认证身份配置OpenShift Container Platform用户时用作提示。

失败响应

  • 401响应表示身份验证失败。

  • 非200状态或存在非空的“error”键表示错误：{"error":"Error message"}