第 9 章 使用服务帐户作为 OAuth 客户端


9.1. 服务帐户作为 OAuth 客户端

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

  • user:info
  • user:check-access
  • role:<any_role>:<service_account_namespace>
  • role:<any_role>:<service_account_namespace>:!

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

  • client_idsystem: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 必须与服务帐户上的注解匹配。

9.1.1. 重定向作为 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"

上例中的 firstsecond 后缀用于分隔两个有效的重定向 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 视为无效。部分提供覆盖数据的格式如下:

类型语法

Scheme

"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:8000https://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"
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.