$ oc sa get-token <service_account_name>
×
使用服务帐户作为 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 令牌。例如 -
要获取
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 可能不够用。例如，您可能希望将路由的所有 Ingress 都视为有效。这就是通过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的路由。因此，该路由的所有 Ingress 现在都将被视为有效。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的Ingress，现在https://example.com/custompath被视为有效，但https://example.com无效。部分提供覆盖数据的格式如下
| 类型 | 语法 |
|---|---|
方案 |
"https://" |
主机名 |
"//website.com" |
端口 |
"//:8000" |
路径 |
"examplepath" |
|
指定主机名覆盖将替换来自引用对象的 hostname 数据，这不太可能是期望的行为。 |
以上任何语法组合都可以使用以下格式组合
<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 的 Ingress，则 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"