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

使用服务账号作为 OAuth 客户端

服务账户作为OAuth客户端

您可以将服务账户用作受约束形式的OAuth客户端。服务账户只能请求允许访问某些基本用户信息和服务账户自身命名空间内基于角色的权限的子集范围。

  • user:info

  • user:check-access

  • role:<any_role>:<service_account_namespace>

  • role:<any_role>:<service_account_namespace>:!

使用服务账户作为OAuth客户端时

  • client_id 为 system:serviceaccount:<service_account_namespace>:<service_account_name>。

  • client_secret 可以是该服务账户的任何API令牌。例如

    $ oc sa get-token <service_account_name>

  • 要获取WWW-Authenticate 质询，请在服务账户上设置serviceaccounts.openshift.io/oauth-want-challenges 注释为true。

  • redirect_uri 必须与服务账户上的注释匹配。

服务账户作为OAuth客户端的重定向URI

注释键必须以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)
  }
}
1 kind 指的是被引用对象的类型。目前，只支持route。
2 name 指的是对象的名称。该对象必须与服务账户位于同一命名空间。
3 group 指的是对象的组。保留为空，因为路由的组为空字符串。

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

"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 不被视为有效。部分提供覆盖数据的格式如下

类型 语法

方案

"https://"

主机名

"//website.com"

端口

"//:8000"

路径

"examplepath"

指定主机名覆盖将替换来自引用对象的主机名数据，这可能不是期望的行为。

可以使用以下格式组合上述语法的任何组合

<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"