Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

7.5. 配置请求标头身份提供程序

配置 request-header 身份提供程序，标识请求标头值中的用户，例如 X-Remote-User。它通常与设定请求标头值的身份验证代理一起使用。

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

注意

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

7.5.2. 关于请求标头身份验证
复制链接

请求标头身份提供程序从请求标头值标识用户，例如 X-Remote-User。它通常与设定请求标头值的身份验证代理一起使用。请求标头身份提供程序无法与其他使用直接密码登录的身份提供商结合使用 htpasswd、Keystone、LDAP 或基本身份验证。

注意

您还可以将请求标头身份提供程序用于高级配置，如由社区支持的 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。

7.5.2.1. Microsoft Windows 上的 SSPI 连接支持
复制链接

重要

在 Microsoft Windows 上使用 SSPI 连接支持只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

OpenShift CLI （oc）支持安全支持提供程序接口（SSPI），以允许 Microsft Windows 上的 SSO 流。如果您使用请求标头身份提供程序与支持 GSSAPI 的代理将 Active Directory 服务器连接到 OpenShift Container Platform，用户可以通过加入了域的 Microsoft Windows 计算机使用 oc 命令行界面来自动进行 OpenShift Container Platform 身份验证。

7.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
    Copy to Clipboard Toggle word wrap
    提示

    您还可以应用以下 YAML 来创建配置映射： 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: ca-config-map
  namespace: openshift-config
data:
  ca.crt: |
    <CA_certificate_PEM>
    Copy to Clipboard Toggle word wrap

7.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
      - SSO-User
      emailHeaders:
8 

      - X-Remote-User-Email
      nameHeaders:
9 

      - X-Remote-User-Display-Name
      preferredUsernameHeaders:
10 

      - X-Remote-User-Login
Copy to Clipboard Toggle word wrap

1
此提供程序名称作为前缀放在请求标头中的用户名前，以此组成身份名称。
2
控制如何在此提供程序的身份和 User 对象之间建立映射。
3
可选：将未经身份验证的 /oauth/authorize 请求重定向到的 URL，它将身份验证基于浏览器的客户端并将其请求代理到 https://<namespace_route>/oauth/authorize。代理到 https://<namespace_route>/oauth/authorize 的 URL 必须以 /authorize 结尾（不含尾部斜杠）,以及代理子路径，以便 OAuth 批准流可以正常工作。${url} 替换为当前的 URL，进行转义以在查询参数中安全使用。把 ${query} 替换为当前的查询字符串。如果未定义此属性，则必须使用 loginURL。
4
可选：将未经身份验证的 /oauth/authorize 请求重定向到的 URL，它将身份验证期望 WWW-Authenticate challenges 的客户端，然后将它们代理到 https://<namespace_route>/oauth/authorize。${url} 替换为当前的 URL，进行转义以在查询参数中安全使用。把 ${query} 替换为当前的查询字符串。如果未定义此属性，则必须使用 challengeURL。
5
对包含 PEM 编码证书捆绑包的 OpenShift Container Platform ConfigMap 的引用。用作信任定位符，以验证远程服务器出示的 TLS 证书。
重要

自 OpenShift Container Platform 4.1 起，此身份提供程序需要 ca 字段。这意味着您的代理必须支持 mutual TLS。

6
可选：通用名称 (cn) 的列表。如果设定，则必须出示带有指定列表中通用名称 (cn) 的有效客户端证书，然后才能检查请求标头中的用户名。如果为空，则允许任何通用名称。只能与 ca 结合使用。
7
按顺序查找用户身份的标头名称。第一个包含值的标头被用作身份。必需，不区分大小写。
8
按顺序查找电子邮件地址的标头名称。第一个包含值的标头被用作电子邮件地址。可选，不区分大小写。
9
按顺序查找显示名称的标头名称。第一个包含值的标头被用作显示名称。可选，不区分大小写。
10
按顺序查找首选用户名的标头名称（如果与通过 headers 中指定的标头确定的不可变身份不同）。在置备时，第一个包含值的标头用作首选用户名。可选，不区分大小写。

7.5.5. 在集群中添加身份提供程序
复制链接

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

先决条件

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

流程

  1. 应用定义的 CR： 

    $ oc apply -f </path/to/CR>
    Copy to Clipboard Toggle word wrap
    注意

    如果一个 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>
    Copy to Clipboard Toggle word wrap

  3. 确认用户登录成功，并显示用户名。 

    $ oc whoami
    Copy to Clipboard Toggle word wrap

本例使用请求标头身份提供程序为 OpenShift Container Platform 配置 Apache 验证代理服务器。

7.5.6.1. 自定义代理配置
复制链接

使用 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?…​。
注意

https://<namespace_route> 地址是到 OAuth 服务器的路由，可通过运行 oc get route -n openshift-authentication 获取。

7.5.6.2. 使用请求标头配置 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
    1
    Copy to Clipboard Toggle word wrap
    1
    证书颁发机构必须存储在 ConfigMap 的 ca.crt 键中。
    提示

    您还可以应用以下 YAML 来创建配置映射： 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: ca-config-map
  namespace: openshift-config
data:
  ca.crt: |
    <CA_certificate_PEM>
    Copy to Clipboard Toggle word wrap
  • 示例：为代理生成客户端证书您可以使用任何 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
# 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

      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
    Copy to Clipboard Toggle word wrap
    注意

    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
    Copy to Clipboard Toggle word wrap

  4. 验证配置：

    1. 通过提供正确的客户端证书和标头，确认您可以通过请求令牌来绕过代理： 

      # curl -L -k -H "X-Remote-User: joe" \
   --cert /etc/pki/tls/certs/authproxy.pem \
   https://<namespace_route>/oauth/token/request
      Copy to Clipboard Toggle word wrap

    2. 通过在没有证书的情况下请求令牌，确认没有提供客户端证书的请求会失败： 

      # curl -L -k -H "X-Remote-User: joe" \
   https://<namespace_route>/oauth/token/request
      Copy to Clipboard Toggle word wrap

    3. 确认 challengeURL 重定向已启用： 

      # curl -k -v -H 'X-Csrf-Token: 1' \
   https://<namespace_route>/oauth/authorize?client_id=openshift-challenging-client&response_type=token
      Copy to Clipboard Toggle word wrap

      复制 challengeURL 重定向，以用于下一步骤。

    4. 运行这个命令会显示一个带有 WWW-Authenticate 基本质询，协商质询或两个质询都有的 401 响应： 

      # curl -k -v -H 'X-Csrf-Token: 1' \
   <challengeURL_redirect + query>
      Copy to Clipboard Toggle word wrap

    5. 测试在使用 Kerberos ticket 和不使用 Kerberos ticket 的情况下登录到 OpenShift CLI（oc）：

      1. 如果您使用 kinit生成了 Kerberos ticket，请将其销毁： 

        # kdestroy -c cache_name
        1
        Copy to Clipboard Toggle word wrap
        1
        请确定提供 Kerberos 缓存的名称。

      2. 使用您的 Kerberos 凭证登录到 oc： 

        # oc login -u <username>
        Copy to Clipboard Toggle word wrap

        在提示符后输入您的 Kerberos 密码。

      3. 注销 oc 工具： 

        # oc logout
        Copy to Clipboard Toggle word wrap

      4. 使用您的 Kerberos 凭证获得一个 ticket： 

        # kinit
        Copy to Clipboard Toggle word wrap

        在提示符后输入您的 Kerberos 用户名和密码。

      5. 确认您可以登录到 oc： 

        # oc login
        Copy to Clipboard Toggle word wrap

        如果配置正确，您会在不需要单独输入凭证的情况下成功登录。

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat