×

配置request-header身份提供程序以从请求头值(例如X-Remote-User)识别用户。它通常与设置请求头值的认证代理一起使用。

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

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

OpenShift Container Platform 用户名不支持包含/:%

关于请求头身份验证

请求头身份提供程序从请求头值(例如X-Remote-User)识别用户。它通常与设置请求头值的认证代理一起使用。请求头身份提供程序不能与其他使用直接密码登录的身份提供程序(例如 htpasswd、Keystone、LDAP 或基本身份验证)结合使用。

您还可以将请求头身份提供程序用于高级配置,例如社区支持的SAML 身份验证。请注意,Red Hat 不支持此解决方案。

为了让用户使用此身份提供程序进行身份验证,他们必须通过认证代理访问https://<namespace_route>/oauth/authorize(以及子路径)。为此,请将 OAuth 服务器配置为将未经身份验证的 OAuth 令牌请求重定向到代理到https://<namespace_route>/oauth/authorize的代理端点。

要重定向期望基于浏览器的登录流程的客户端的未经身份验证的请求

  • provider.loginURL参数设置为将对交互式客户端进行身份验证,然后将请求代理到https://<namespace_route>/oauth/authorize的认证代理 URL。

要重定向期望WWW-Authenticate质询的客户端的未经身份验证的请求

  • provider.challengeURL参数设置为将对期望WWW-Authenticate质询的客户端进行身份验证,然后将请求代理到https://<namespace_route>/oauth/authorize的认证代理 URL。

provider.challengeURLprovider.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 开始,您的代理必须支持双向 TLS。

Microsoft Windows 上的 SSPI 连接支持

在 Microsoft Windows 上使用 SSPI 连接支持仅是技术预览功能。技术预览功能不受 Red Hat 生产服务级别协议 (SLA) 的支持,并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能可让您抢先体验即将推出的产品功能,使客户能够在开发过程中测试功能并提供反馈。

有关 Red Hat 技术预览功能的支持范围的更多信息,请参见技术预览功能支持范围

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

创建配置映射

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

    或者,您可以应用以下 YAML 来创建配置映射

    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: 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
1 此提供程序名称作为前缀添加到请求头中的用户名中,以形成身份名称。
2 控制在此提供程序的身份和User对象之间如何建立映射。
3 可选:将未经身份验证的/oauth/authorize请求重定向到的 URL,该 URL 将对基于浏览器的客户端进行身份验证,然后将其请求代理到https://<namespace_route>/oauth/authorize。代理到https://<namespace_route>/oauth/authorize的 URL 必须以/authorize结尾(不带尾部斜杠),并且还必须代理子路径,才能使 OAuth 批准流程正常工作。${url} 将替换为当前 URL,并进行转义以确保在查询参数中安全。${query} 将替换为当前查询字符串。如果未定义此属性,则必须使用loginURL
4 可选:将未经身份验证的/oauth/authorize请求重定向到的 URL,该 URL 将对期望WWW-Authenticate质询的客户端进行身份验证,然后将其代理到https://<namespace_route>/oauth/authorize${url} 将替换为当前 URL,并进行转义以确保在查询参数中安全。${query} 将替换为当前查询字符串。如果未定义此属性,则必须使用challengeURL
5 包含 PEM 编码证书捆绑包的 OpenShift Container Platform ConfigMap对象的引用。用作验证远程服务器提供的 TLS 证书的信任锚。

从 OpenShift Container Platform 4.1 开始,此身份提供程序需要ca字段。这意味着您的代理必须支持双向 TLS。

6 可选:常用名 (cn) 列表。如果设置,则必须在检查请求头以查找用户名之前呈现具有指定列表中的常用名 (cn) 的有效客户端证书。如果为空,则允许任何常用名。只能与ca结合使用。
7 按顺序检查用户身份的标头名称。包含值的第一个标头将用作身份。必需,不区分大小写。
8 按顺序检查电子邮件地址的标头名称。包含值的第一个标头将用作电子邮件地址。可选,不区分大小写。
9 按顺序检查显示名称的标头名称。包含值的第一个标头将用作显示名称。可选,不区分大小写。
10 按顺序检查首选用户名(如果与从headers中指定的标头确定的不可变身份不同)的标头名称。在预配时,包含值的第一个标头将用作首选用户名。可选,不区分大小写。
其他资源
  • 有关参数(例如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 身份验证配置示例

此示例使用请求头身份提供程序配置 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?…​

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

使用请求头配置 Apache 身份验证

此示例使用mod_auth_gssapi模块使用请求头身份提供程序配置 Apache 身份验证代理。

先决条件
  • 可选频道获取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)
    1 CA 必须存储在ConfigMap对象的ca.crt密钥中。

    或者,您可以应用以下 YAML 来创建配置映射

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: ca-config-map
      namespace: openshift-config
    data:
      ca.crt: |
        <CA_certificate_PEM>
  • 为代理生成客户端证书。您可以使用任何 x509 证书工具生成此证书。客户端证书必须由您为验证提交受信任标头的请求生成的 CA 签名。

  • 为您的身份提供程序创建自定义资源 (CR)。

步骤

此代理使用客户端证书连接到 OAuth 服务器,该服务器配置为信任X-Remote-User标头。

  1. 为 Apache 配置创建证书。您指定为SSLProxyMachineCertificateFile参数值的证书是用于将代理身份验证到服务器的代理的客户端证书。它必须使用TLS Web Client Authentication作为扩展密钥类型。

  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

    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. 验证配置。

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

      # curl -L -k -H "X-Remote-User: joe" \
         --cert /etc/pki/tls/certs/authproxy.pem \
         https://<namespace_route>/oauth/token/request
    2. 确认没有提供客户端证书的请求会失败,方法是请求没有证书的令牌。

      # curl -L -k -H "X-Remote-User: joe" \
         https://<namespace_route>/oauth/token/request
    3. 确认challengeURL重定向处于活动状态。

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

      复制challengeURL重定向,以便在下一步中使用。

    4. 运行此命令以显示带有WWW-Authenticate基本挑战、协商挑战或两种挑战的401响应。

      # curl -k -v -H 'X-Csrf-Token: 1' \
         <challengeURL_redirect + query>
    5. 测试使用和不使用 Kerberos 票证登录 OpenShift CLI (oc)。

      1. 如果您使用kinit生成了 Kerberos 票证,请将其销毁。

        # kdestroy -c cache_name (1)
        1 确保提供 Kerberos 缓存的名称。
      2. 使用您的 Kerberos 凭据登录oc工具。

        # oc login -u <username>

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

      3. 注销oc工具。

        # oc logout
      4. 使用您的 Kerberos 凭据获取票证。

        # kinit

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

      5. 确认您可以登录oc工具。

        # oc login

        如果您的配置正确,您无需输入单独的凭据即可登录。