第14章 サービスアカウントの OAuth クライアントとしての使用
14.1. OAuth クライアントとしてのサービスアカウント
サービスアカウントは、OAuth クライアントの制限されたフォームで使用できます。サービスアカウントは一部の基本ユーザー情報へのアクセスを許可するスコープのサブセットと、サービスアカウント自体の namespace 内のロールベースの権限のみを要求できます。
-
user:info
-
user:check-access
-
role:<any_role>:<serviceaccount_namespace>
-
role:<any_role>:<serviceaccount_namespace>:!
サービスアカウントを OAuth クライアントとして使用する場合:
-
client_id
はsystem:serviceaccount:<serviceaccount_namespace>:<serviceaccount_name>
になります。 client_secret
には、サービスアカウントの API トークンのいずれかを指定できます。以下は例になります。$ oc sa get-token <serviceaccount_name>
-
WWW-Authenticate
チャレンジを取得するには、サービスアカウントのserviceaccounts.openshift.io/oauth-want-challenges
アノテーションをtrue
に設定します。 -
redirect_uri
は、サービスアカウントのアノテーションに一致する必要があります。
14.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://" |
Hostname | "//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"