第 4 章 其他概念

对 OpenShift Container Platform API 的请求可以包含 Impersonate-User 标头，这表示请求者希望像来自指定用户一样处理请求。您可以通过在请求中添加 --as=<user> 标志来模拟用户。

在用户 A 可以模拟用户 B 之前，用户 A 通过了身份验证。然后，进行授权检查以确保 User A 可以模仿名为 User B 的用户。如果用户 A 请求模拟服务帐户 system:serviceaccount:namespace:name，OpenShift Container Platform 会确认 User A 可以模仿名为 name 的 serviceaccount 在 命名空间中。如果检查失败，请求会失败，并显示 403(Forbidden)错误代码。

默认情况下，项目管理员和编辑器可以模拟其命名空间中的服务帐户。sudoers 角色允许用户模拟 system:admin，后者具有集群管理员权限。通过模拟 system:admin，可以在用户管理集群时提供一定的拼写错误（而非安全性）的保护。例如，运行 oc delete nodes --all 会失败，但运行 oc delete nodes --all --as=system:admin 会失败。您可以运行以下命令来授予该权限的用户：

$ oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --user=<username>

如果您需要代表用户创建项目请求，请在命令中包含 --as=<user> --as-group=<group1> --as-group=<group2> 标志。因为 system:authenticated:oauth 是唯一可以创建项目请求的 bootstrap 组，所以您必须模拟该组，如下例所示：

$ oc new-project <project> --as=<user> \
--as-group=system:authenticated --as-group=system:authenticated:oauth

每个对 OAuth 令牌的请求都必须指定要接收和使用令牌的 OAuth 客户端。启动 OpenShift Container Platform API 时会自动创建以下 OAuth 客户端：

注册其他客户端：

$ oc create -f <(echo '
kind: OAuthClient
apiVersion: oauth.openshift.io/v1
metadata:
 name: demo 1
secret: "..." 2
redirectURIs:
 - "http://www.example.com/" 3
grantMethod: prompt 4
')

服务帐户可用作受约束形式的 OAuth 客户端。服务帐户只能请求范围的子集，允许访问服务帐户本身的命名空间内的一些基本用户信息和基于角色的功能：

在将服务帐户用作 OAuth 客户端时：

注解键必须具有前缀 serviceaccounts.openshift.io/oauth-redirecturi. 或 serviceaccounts.openshift.io/oauth-redirectreference.，例如：

serviceaccounts.openshift.io/oauth-redirecturi.<name>

采用最简单形式时，注解可用于直接指定有效的重定向 URI。例如：

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "https://example.com"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"

上例中的 first 和 second 后缀用于分隔两个有效的重定向 URI。

在更复杂的配置中，静态重定向 URI 可能还不够。例如，您可能希望路由的所有入口都被视为有效。这时可使用通过 serviceaccounts.openshift.io/oauth-redirectreference. 前缀的动态重定向 URI。

例如：

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

由于此注解的值包含序列化 JSON 数据，因此在扩展格式中可以更轻松地查看：

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": "Route",
    "name": "jenkins"
  }
}

您现在可以看到，OAuthRedirectReference 允许引用名为 jenkins 的路由。因此，该路由的所有入口现在都被视为有效。OAuthRedirectReference 的完整规格是：

{
  "kind": "OAuthRedirectReference",
  "apiVersion": "v1",
  "reference": {
    "kind": ..., 1
    "name": ..., 2
    "group": ... 3
  }
}

可以合并这两个注解前缀，来覆盖引用对象提供的数据。例如：

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

first 后缀用于将注解绑在一起。假设 jenkins 路由的入口为 https://example.com，现在 https://example.com/custompath 被视为有效，但 https://example.com 视为无效。部分提供覆盖数据的格式如下：

以上语法的任何组合都可以使用以下格式进行合并：

<scheme:>//<hostname><:port>/<path>

同一对象可以被多次引用，以获得更大的灵活性：

"serviceaccounts.openshift.io/oauth-redirecturi.first":  "custompath"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second":  "//:8000"
"serviceaccounts.openshift.io/oauth-redirectreference.second": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"

假设名为 jenkins 的路由具有入口 https://example.com，则 https://example.com:8000 和 https://example.com/custompath 都被视为有效。

可以同时使用静态和动态注解，以实现所需的行为：

"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"

$ oc get events | grep ServiceAccount

1m         1m          1         proxy                    ServiceAccount                                  Warning   NoSAOAuthRedirectURIs   service-account-oauth-client-getter   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

$ oc describe sa/proxy | grep -A5 Events

Events:
  FirstSeen     LastSeen        Count   From                                    SubObjectPath   Type            Reason                  Message
  ---------     --------        -----   ----                                    -------------   --------        ------                  -------
  3m            3m              1       service-account-oauth-client-getter                     Warning         NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

Reason                  Message
NoSAOAuthRedirectURIs   system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>

Reason                  Message
NoSAOAuthRedirectURIs   [routes.route.openshift.io "<name>" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

Reason                  Message
NoSAOAuthRedirectURIs   [no kind "<name>" is registered for version "v1", system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]

Reason                  Message
NoSAOAuthTokens         system:serviceaccount:myproject:proxy has no tokens

所有对 OAuth 令牌的请求都包括对 <master>/oauth/authorize 的请求。大多数身份验证集成在此端点前放置身份验证代理，或者将 OpenShift Container Platform 配置为针对后备 身份提供程序 验证凭证。对 <master>/oauth/authorize 的请求可能来自不能显示交互式登录页面的用户代理，如 CLI。因此，除了交互式登录流程外，OpenShift Container Platform 也支持使用 WWW-Authenticate 质询进行验证。

如果在 <master>/oauth/authorize 端点前面放置身份验证代理，它会向未经身份验证的非浏览器用户代理发送 WWW-Authenticate 质询，而不是显示交互式登录页面或重定向到交互式登录流程。

在 OpenShift Container Platform 中运行的应用可能需要发现有关内置 OAuth 服务器的信息。例如，他们可能需要发现没有手工配置的 <master> 服务器的地址。为此，OpenShift Container Platform 实施了 IETF OAuth 2.0 授权服务器元数据草案规范。

因此，集群中运行的任何应用程序都可以向 https://openshift.default.svc/.well-known/oauth-authorization-server 发出 GET 请求来获取以下信息：

{
  "issuer": "https://<master>", 1
  "authorization_endpoint": "https://<master>/oauth/authorize", 2
  "token_endpoint": "https://<master>/oauth/token", 3
  "scopes_supported": [ 4
    "user:full",
    "user:info",
    "user:check-access",
    "user:list-scoped-projects",
    "user:list-projects"
  ],
  "response_types_supported": [ 5
    "code",
    "token"
  ],
  "grant_types_supported": [ 6
    "authorization_code",
    "implicit"
  ],
  "code_challenge_methods_supported": [ 7
    "plain",
    "S256"
  ]
}

OAuth 服务器支持标准的授权代码授权和隐式授权 OAuth 授权流。

运行以下命令，使用授权代码授权方法请求 OAuth 令牌：

$ curl -H "X-Remote-User: <username>" \
     --cacert /etc/origin/master/ca.crt \
     --cert /etc/origin/master/admin.crt \
     --key /etc/origin/master/admin.key \
     -I https://<master-address>/oauth/authorize?response_type=token\&client_id=openshift-challenging-client | grep -oP "access_token=\K[^&]*"

在使用隐式授权流 (response_type=token) 以及配置为请求 WWW-Authenticate 质询（如 openshift-challenging-client）的 client_id 以请求 OAuth 令牌时，可能来自 /oauth/authorize 的服务器响应及它们的处理方式如下方所列：

使用隐式授权流请求 OAuth 令牌：

$ curl -u <username>:<password>
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' -skv / 1
/ -H "X-CSRF-Token: xxx" 2

*   Trying 10.64.33.43...
* Connected to 10.64.33.43 (10.64.33.43) port 8443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 592 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256
*        server certificate verification SKIPPED
*        server certificate status verification SKIPPED
*        common name: 10.64.33.43 (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: CN=10.64.33.43
*        start date: Thu, 09 Aug 2018 04:00:39 GMT
*        expire date: Sat, 08 Aug 2020 04:00:40 GMT
*        issuer: CN=openshift-signer@1531109367
*        compression: NULL
* ALPN, server accepted to use http/1.1
* Server auth using Basic with user 'developer'
> GET /oauth/authorize?client_id=openshift-challenging-client&response_type=token HTTP/1.1
> Host: 10.64.33.43:8443
> Authorization: Basic ZGV2ZWxvcGVyOmRzc2Zkcw==
> User-Agent: curl/7.47.0
> Accept: */*
> X-CSRF-Token: xxx
>
< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location:
https://10.64.33.43:8443/oauth/token/implicit#access_token=gzTwOq_mVJ7ovHliHBTgRQEEXa1aCZD9lnj7lSw3ekQ&expires_in=86400&scope=user%3Afull&token_type=Bearer 1
< Pragma: no-cache
< Set-Cookie: ssn=MTUzNTk0OTc1MnxIckVfNW5vNFlLSlF5MF9GWEF6Zm55Vl95bi1ZNE41S1NCbFJMYnN1TWVwR1hwZmlLMzFQRklzVXRkc0RnUGEzdnBEa0NZZndXV2ZUVzN1dmFPM2dHSUlzUmVXakQ3Q09rVXpxNlRoVmVkQU5DYmdLTE9SUWlyNkJJTm1mSDQ0N2pCV09La3gzMkMzckwxc1V1QXpybFlXT2ZYSmI2R2FTVEZsdDBzRjJ8vk6zrQPjQUmoJCqb8Dt5j5s0b4wZlITgKlho9wlKAZI=; Path=/; HttpOnly; Secure
< Date: Mon, 03 Sep 2018 04:42:32 GMT
< Content-Length: 0
< Content-Type: text/plain; charset=utf-8
<
* Connection #0 to host 10.64.33.43 left intact

要只查看 OAuth 令牌值，请运行以下命令：

$ curl -u <username>:<password> /
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' / 1
-skv -H "X-CSRF-Token: xxx" --stderr - |  grep -oP "access_token=\K[^&]*" 2

hvqxe5aMlAzvbqfM2WWw3D6tR0R2jCQGKx0viZBxwmc

您还可以使用 Code Grant 方法请求令牌。

OpenShift Container Platform 在身份验证尝试过程中捕获以下 Prometheus 系统指标：