$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config
配置request-header
身份提供程序以从请求头值(例如X-Remote-User
)识别用户。它通常与设置请求头值的认证代理一起使用。
默认情况下,集群中只存在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.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 开始,您的代理必须支持双向 TLS。 |
在 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 来创建配置映射
|
以下自定义资源 (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 证书的信任锚。
|
||
6 | 可选:常用名 (cn ) 列表。如果设置,则必须在检查请求头以查找用户名之前呈现具有指定列表中的常用名 (cn ) 的有效客户端证书。如果为空,则允许任何常用名。只能与ca 结合使用。 |
||
7 | 按顺序检查用户身份的标头名称。包含值的第一个标头将用作身份。必需,不区分大小写。 | ||
8 | 按顺序检查电子邮件地址的标头名称。包含值的第一个标头将用作电子邮件地址。可选,不区分大小写。 | ||
9 | 按顺序检查显示名称的标头名称。包含值的第一个标头将用作显示名称。可选,不区分大小写。 | ||
10 | 按顺序检查首选用户名(如果与从headers 中指定的标头确定的不可变身份不同)的标头名称。在预配时,包含值的第一个标头将用作首选用户名。可选,不区分大小写。 |
有关参数(例如mappingMethod
)的信息,这些参数对所有身份提供程序都是通用的,请参见身份提供程序参数。
安装集群后,向其中添加身份提供程序,以便您的用户可以进行身份验证。
创建一个 OpenShift Container Platform 集群。
为您的身份提供程序创建自定义资源 (CR)。
您必须以管理员身份登录。
应用已定义的 CR
$ oc apply -f </path/to/CR>
如果 CR 不存在, |
使用您的身份提供商的用户身份登录集群,并在提示时输入密码。
$ oc login -u <username>
确认用户已成功登录并显示用户名。
$ oc whoami
此示例使用请求头身份提供程序配置 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?…
。
|
此示例使用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 来创建配置映射
|
为代理生成客户端证书。您可以使用任何 x509 证书工具生成此证书。客户端证书必须由您为验证提交受信任标头的请求生成的 CA 签名。
为您的身份提供程序创建自定义资源 (CR)。
此代理使用客户端证书连接到 OAuth 服务器,该服务器配置为信任X-Remote-User
标头。
为 Apache 配置创建证书。您指定为SSLProxyMachineCertificateFile
参数值的证书是用于将代理身份验证到服务器的代理的客户端证书。它必须使用TLS Web Client Authentication
作为扩展密钥类型。
创建 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
|
更新自定义资源 (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
验证配置。
确认您可以通过提供正确的客户端证书和标头来请求令牌来绕过代理。
# curl -L -k -H "X-Remote-User: joe" \
--cert /etc/pki/tls/certs/authproxy.pem \
https://<namespace_route>/oauth/token/request
确认没有提供客户端证书的请求会失败,方法是请求没有证书的令牌。
# curl -L -k -H "X-Remote-User: joe" \
https://<namespace_route>/oauth/token/request
确认challengeURL
重定向处于活动状态。
# curl -k -v -H 'X-Csrf-Token: 1' \
https://<namespace_route>/oauth/authorize?client_id=openshift-challenging-client&response_type=token
复制challengeURL
重定向,以便在下一步中使用。
运行此命令以显示带有WWW-Authenticate
基本挑战、协商挑战或两种挑战的401
响应。
# curl -k -v -H 'X-Csrf-Token: 1' \
<challengeURL_redirect + query>
测试使用和不使用 Kerberos 票证登录 OpenShift CLI (oc
)。
如果您使用kinit
生成了 Kerberos 票证,请将其销毁。
# kdestroy -c cache_name (1)
1 | 确保提供 Kerberos 缓存的名称。 |
使用您的 Kerberos 凭据登录oc
工具。
# oc login -u <username>
在提示符处输入您的 Kerberos 密码。
注销oc
工具。
# oc logout
使用您的 Kerberos 凭据获取票证。
# kinit
在提示符处输入您的 Kerberos 用户名和密码。
确认您可以登录oc
工具。
# oc login
如果您的配置正确,您无需输入单独的凭据即可登录。