第9章 サービスアカウントの OAuth クライアントとしての使用
9.1. OAuth クライアントとしてのサービスアカウント
サービスアカウントは、OAuth クライアントの制限されたフォームで使用できます。サービスアカウントは一部の基本ユーザー情報へのアクセスを許可するスコープのサブセットと、サービスアカウント自体の namespace 内のロールベースの権限のみを要求できます。
-
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は、サービスアカウントのアノテーションに一致する必要があります。
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"
上記の例の first および second ポストフィックスは 2 つの有効なリダイレクト 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
}
}アノテーションはどちらも、接頭辞も組み合わせて、参照オブジェクトで提供されるデータをオーバーライドできます。以下に例を示します。
"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" |
ホスト名のオーバーライドを指定すると、参照されるオブジェクトのホスト名データが置き換わりますが、これは望ましい動作ではありません。
上記の構文のいずれの組み合わせも、以下のフォーマットを使って実行できます。
<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"