第4章 追加の概念
4.1. 認証 リンクのコピーリンクがクリップボードにコピーされました!
4.1.1. 概要 リンクのコピーリンクがクリップボードにコピーされました!
認証層は、OpenShift Container Platform API への要求に関連付けられたユーザーを識別します。次に、認可層は要求が許可されるかどうかを判別するために要求側のユーザーについての情報を使用します。
管理者として、マスター設定ファイルを使用して、認証の設定を実行できます。
4.1.2. ユーザーとグループ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform の ユーザー は、OpenShift Container Platform API に要求できるエンティティーです。通常、これは OpenShift Container Platform と対話している開発者または管理者のアカウントを表します。
ユーザーは 1 つ以上の グループ に割り当てることができます。それぞれのグループはユーザーの特定のセットを表します。グループは、認可ポリシーを管理 し、個々のユーザーにではなく、一度に複数ユーザーにパーミッションを付与する場合などに役立ちます。たとえば、アクセスをユーザーに個別に付与するのではなく、プロジェクト 内の複数の オブジェクト に対するアクセスを許可できます。
明示的に定義されるグループのほかにも、システムグループまたは 仮想グループ が OpenShift で自動的にプロビジョニングされます。これらは、クラスターのバインディングを表示 する際に確認できます。
仮想グループのデフォルトセットでは、とくに以下の点に留意してください。
仮想グループ | 説明 |
---|---|
system:authenticated | 認証されたユーザーに自動的に関連付けられます。 |
system:authenticated:oauth | OAuth アクセストークンで認証されたすべてのユーザーに自動的に関連付けられます。 |
system:unauthenticated | 認証されていないすべてのユーザーに自動的に関連付けられます。 |
4.1.3. API 認証 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform API への要求は以下の方法で認証されます。
- OAuth アクセストークン
-
<master>/oauth/authorize
および<master>/oauth/token
エンドポイントを使用して OpenShift Container Platform OAuth サーバーから取得されます。 -
Authorization: Bearer…
ヘッダーとして送信されます。 -
websocket 要求の
base64url.bearer.authorization.k8s.io.<base64url-encoded-token>
形式の websocket サブプロトコルヘッダーとして送信されます。
-
- X.509 クライアント証明書
- API サーバーへの HTTPS 接続を要求します。
- 信頼される認証局バンドルに対して API サーバーによって検証されます。
- API サーバーは証明書を作成し、これをコントローラーに配布してそれらを認証できるようにします。
無効なアクセストークンまたは無効な証明書での要求は認証層によって拒否され、401 エラーが出されます。
アクセストークンまたは証明証が提供されない場合、認証層は system:anonymous
仮想ユーザーおよび system:unauthenticated
仮想グループを要求に割り当てます。これにより、認可層は匿名ユーザーが実行できる要求 (ある場合) を決定できます。
4.1.3.1. 権限借用 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform API への要求いは、要求側が要求を指定されたユーザーからのものであるかのように処理されることを希望することを示す、Impersonate-User ヘッダーが含まれる場合があります。このユーザーのなりすましは、--as=<user>
フラグを要求に追加して実行できます。
ユーザー A によるユーザー B の権限の借用は、ユーザー A が認証された後に可能になります。ユーザー A がユーザー B という名前のユーザーの権限を借用できるように、認証チェックが行われます。ユーザー A が、サービスアカウント system:serviceaccount:namespace:name の権限借用を要求する場合には、OpenShift Container Platform は、ユーザー A が namespace の name という名前のserviceaccount の権限を借用できることを確認します。チェックに失敗すると、この要求は 403 (Forbidden) エラーコードで失敗します。
デフォルトで、プロジェクト管理者およびエディターは、その namespace に含まれるサービスアカウントの権限を借用できます。ユーザーは、sudoer ロールを使用して、system:admin の権限を借用できるので、クラスター管理者のパーミッションが使えるようになります。system:admin の権限を借用できることで、誤植の発生を防ぐことはできますが、クラスターの管理者に対してセキュリティーを確保するわけではありません。たとえば、oc delete nodes --all
を実行すると失敗するにもかかわらず、oc delete nodes --all --as=system:admin
を実行すると成功します。以下のコマンドを実行してユーザーにこのパーミッションを付与できます。
oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --user=<username>
$ oc create clusterrolebinding <any_valid_name> --clusterrole=sudoer --user=<username>
ユーザーの代わりにプロジェクトの要求を作成する必要がある場合、--as=<user> --as-group=<group1> --as-group=<group2>
フラグをコマンドに組み込みます。system:authenticated:oauth
はプロジェクト要求を作成できる唯一のブートストラップグループであるため、そのグループを以下の例に示されるようになりすます必要があります。
oc new-project <project> --as=<user> \ --as-group=system:authenticated --as-group=system:authenticated:oauth
$ oc new-project <project> --as=<user> \
--as-group=system:authenticated --as-group=system:authenticated:oauth
4.1.4. OAuth リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform マスターには、組み込まれた OAuth サーバーが含まれます。ユーザーは OAuth アクセストークンを取得して、API に対して認証します。
新しい OAuth のトークンが要求されると、OAuth サーバーは設定済みの アイデンティティプロバイダー を使用して要求したユーザーのアイデンティティーを判別します。
次に、そのアイデンティティーがマップするユーザーを判別し、そのユーザーのアクセスユーザーを作成し、使用できるようにトークンを返します。
4.1.4.1. OAuth クライアント リンクのコピーリンクがクリップボードにコピーされました!
OAuth トークンのすべての要求は、トークンを受信し、使用する OAuth クライアントを指定する必要があります。以下の OAuth クライアントは、OpenShift Container Platform API の起動時に自動的に作成されます。
OAuth クライアント | 使用法 |
---|---|
openshift-web-console | Web コンソールのトークンを要求します。 |
openshift-browser-client |
対話式ログインを処理できるユーザーエージェントで |
openshift-challenging-client |
|
追加のクライアントを登録するには、以下を実行します。
- 1
<master>/oauth/authorize
および<master>/oauth/token
への要求を実行する際には、OAuth クライアントのname
がclient_id
パラメーターとして使用されます。- 2
<master>/oauth/token
への要求の実行時に、secret
はclient_secret
パラメーターとして使用されます。- 3
<master>/oauth/authorize
および<master>/oauth/token
への要求で指定されるredirect_uri
パラメーターは、redirectURIs
のいずれかに等しい (またはこれによって接頭辞が付けられた) 状態でなければなりません。- 4
grantMethod
は、このクライアントがトークンを要求するものの、ユーザーによってアクセスが付与されていない場合に実行するアクションを判別するために使用されます。Grant Options に表示されるものと同じ値を使用します。
4.1.4.2. 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>
$ oc sa get-token <serviceaccount_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
WWW-Authenticate
チャレンジを取得するには、サービスアカウントのserviceaccounts.openshift.io/oauth-want-challenges
アノテーションを true に設定します。 -
redirect_uri
は、サービスアカウントのアノテーションに一致する必要があります。詳細は、OAuth クライアントとしてのサービスアカウントの URI のリダイレクト を参照してください。
4.1.4.3. OAuth クライアントとしてのサービスアカウントの URI のリダイレクト リンクのコピーリンクがクリップボードにコピーされました!
アノテーションキーには、以下のように接頭辞 serviceaccounts.openshift.io/oauth-redirecturi.
または serviceaccounts.openshift.io/oauth-redirectreference.
が含まれる必要があります。
serviceaccounts.openshift.io/oauth-redirecturi.<name>
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"
"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\"}}"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
このアノテーションの値にはシリアライズされた JSON データが含まれるため、これを拡張フォーマットで表示するとより容易になります。
ここでは、OAuthRedirectReference
により jenkins
という名前のルートを参照できます。そのため、そのルートのすべての ingress は有効とみなされます。OAuthRedirectReference
の詳細な仕様は以下のようになります。
アノテーションはどちらも、接頭辞も組み合わせて、参照オブジェクトで提供されるデータをオーバーライドできます。以下に例を示します。
"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.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\"}}"
"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"
"serviceaccounts.openshift.io/oauth-redirectreference.first": "{\"kind\":\"OAuthRedirectReference\",\"apiVersion\":\"v1\",\"reference\":{\"kind\":\"Route\",\"name\":\"jenkins\"}}"
"serviceaccounts.openshift.io/oauth-redirecturi.second": "https://other.com"
4.1.4.3.1. OAuth の API イベント リンクのコピーリンクがクリップボードにコピーされました!
API サーバーは、API マスターログへの直接的なアクセスがないとデバッグが困難な unexpected condition のエラーメッセージを返すことがあります。このエラーの根本的な理由は意図的に非表示にされます。 認証されていないユーザーにサーバーの状態についての情報を提供することを避けるためです。
これらのエラーのサブセットは、サービスアカウントの OAuth 設定の問題に関連するものです。これらの問題は、管理者以外のユーザーが確認できるイベントでキャプチャーされます。unexpected condition というサーバーエラーが OAuth の実行時に発生する場合、oc get events
を実行し、これらのイベントについて ServiceAccount
で確認します。
以下の例では、適切な OAuth リダイレクト URI がないサービスアカウントに対して警告しています。
oc get events | grep ServiceAccount
$ oc get events | grep ServiceAccount
出力例
1m 1m 1 proxy ServiceAccount Warning NoSAOAuthRedirectURIs service-account-oauth-client-getter system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>
1m 1m 1 proxy ServiceAccount Warning NoSAOAuthRedirectURIs service-account-oauth-client-getter system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>
oc describe sa/<service-account-name>
を実行すると、指定のサービスアカウント名に関連付けられた OAuth イベントが報告されます。
oc describe sa/proxy | grep -A5 Events
$ oc describe sa/proxy | grep -A5 Events
出力例
Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 3m 3m 1 service-account-oauth-client-getter Warning NoSAOAuthRedirectURIs system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>
Events:
FirstSeen LastSeen Count From SubObjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
3m 3m 1 service-account-oauth-client-getter Warning NoSAOAuthRedirectURIs system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>
以下は生じる可能性のあるイベントエラーの一覧です。
リダイレクト URI アノテーションが指定されていないか、無効な URI が指定されている
Reason Message NoSAOAuthRedirectURIs system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>
Reason Message
NoSAOAuthRedirectURIs system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>
無効なルートが指定されている
Reason Message NoSAOAuthRedirectURIs [routes.route.openshift.io "<name>" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]
Reason Message
NoSAOAuthRedirectURIs [routes.route.openshift.io "<name>" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]
無効な参照タイプが指定されている
Reason Message NoSAOAuthRedirectURIs [no kind "<name>" is registered for version "v1", system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]
Reason Message
NoSAOAuthRedirectURIs [no kind "<name>" is registered for version "v1", system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]
SA トークンがない
Reason Message NoSAOAuthTokens system:serviceaccount:myproject:proxy has no tokens
Reason Message
NoSAOAuthTokens system:serviceaccount:myproject:proxy has no tokens
4.1.4.3.1.1. 誤設定の場合に引き起こされる API イベントのサンプル リンクのコピーリンクがクリップボードにコピーされました!
以下の手順は、ユーザーが破損状態に入る 1 つの経緯とこの問題の解決方法を示しています。
サービスアカウントを OAuth クライアントとして利用するプロジェクトを作成します。
プロキシーサービスアカウントオブジェクトの YAML を作成し、これがルートの
proxy
を使用することを確認します。vi serviceaccount.yaml
$ vi serviceaccount.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサンプルコードを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロキシーへのセキュアな接続を作成するために、ルートオブジェクトの YAML を作成します。
vi route.yaml
$ vi route.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサンプルコードを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow プロキシーをサイドカーとして起動するために、デプロイメント設定の YAML を作成します。
vi proxysidecar.yaml
$ vi proxysidecar.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下のサンプルコードを追加します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 3 つのオブジェクトを作成します。
oc create -f serviceaccount.yaml
$ oc create -f serviceaccount.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc create -f route.yaml
$ oc create -f route.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc create -f proxysidecar.yaml
$ oc create -f proxysidecar.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
oc edit sa/proxy
を実行してサービスアカウントを編集し、serviceaccounts.openshift.io/oauth-redirectreference
アノテーションを、存在しないルートにポイントするように変更します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow OAuth ログでサービスを確認し、サーバーエラーを見つけます。
The authorization server encountered an unexpected condition that prevented it from fulfilling the request.
The authorization server encountered an unexpected condition that prevented it from fulfilling the request.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get events
を実行してServiceAccount
イベントを表示します。oc get events | grep ServiceAccount
$ oc get events | grep ServiceAccount
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 出力例
23m 23m 1 proxy ServiceAccount Warning NoSAOAuthRedirectURIs service-account-oauth-client-getter [routes.route.openshift.io "notexist" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]
23m 23m 1 proxy ServiceAccount Warning NoSAOAuthRedirectURIs service-account-oauth-client-getter [routes.route.openshift.io "notexist" not found, system:serviceaccount:myproject:proxy has no redirectURIs; set serviceaccounts.openshift.io/oauth-redirecturi.<some-value>=<redirect> or create a dynamic URI using serviceaccounts.openshift.io/oauth-redirectreference.<some-value>=<reference>]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.4.4. 統合 リンクのコピーリンクがクリップボードにコピーされました!
OAuth トークンのすべての要求には <master>/oauth/authorize
への要求が必要になります。ほとんどの認証統合では、認証プロキシーをこのエンドポイントの前に配置するか、または OpenShift Container Platform を、サポートする アイデンティティープロバイダー に対して認証情報を検証するように設定します。<master>/oauth/authorize
の要求は、CLI などの対話式ログインページを表示できないユーザーエージェントから送られる場合があります。そのため、OpenShift Container Platform は、対話式ログインフローのほかにも WWW-Authenticate
チャレンジを使用した認証をサポートします。
認証プロキシーが <master>/oauth/authorize
エンドポイントの前に配置される場合、対話式ログインページを表示したり、対話式ログインフローにリダイレクトする代わりに、認証されていない、ブラウザー以外のユーザーエージェントの WWW-Authenticate
チャレンジを送信します。
ブラウザークライアントに対するクロスサイトリクエストフォージェリー (CSRF) 攻撃を防止するため、基本的な認証チャレンジは X-CSRF-Token
ヘッダーが要求に存在する場合にのみ送信されます。基本的な WWW-Authenticate
チャレンジを受信する必要があるクライアントでは、このヘッダーを空でない値に設定する必要があります。
認証プロキシーが WWW-Authenticate
チャレンジをサポートしないか、または OpenShift Container Platform が WWW-Authenticate チャレンジをサポートしないアイデンティティープロバイダーを使用するように設定されている場合、ユーザーはブラウザーで <master>/oauth/token/request
にアクセスし、アクセストークンを手動で取得できます。
4.1.4.5. OAuth サーバーメタデータ リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform で実行されているアプリケーションは、ビルトイン OAuth サーバーについての情報を検出する必要がある場合があります。たとえば、それらは <master>
サーバーのアドレスを手動の設定なしで検出する必要があります。これを支援するために、OpenShift Container Platform は IETF OAuth 2.0 Authorization Server Metadata ドラフト仕様を実装しています。
そのため、クラスター内で実行されているすべてのアプリケーションは、https://openshift.default.svc/.well-known/oauth-authorization-server に対して GET
要求を実行し、以下の情報を取得できます。
- 1
https
スキームを使用し、クエリーまたはフラグメントコンポーネントがない認可サーバーの発行者 ID です。これは、認可サーバーについての情報が含まれる.well-known
RFC 5785 リソースが公開される場所です。- 2
- 認可サーバーの認可エンドポートの URL です。RFC 6749 を参照してください。
- 3
- 認可サーバーのトークンエンドポイントの URL です。RFC 6749 を参照してください。
- 4
- この認可サーバーがサポートする OAuth 2.0 RFC 6749 スコープの値の一覧を含む JSON 配列です。サポートされるスコープの値すべてが公開される訳ではないことに注意してください。
- 5
- この認可サーバーがサポートする OAuth 2.0
response_type
値の一覧を含む JSON 配列です。使用される配列の値は、RFC 7591 の OAuth 2.0 Dynamic Client Registration Protocol で定義されるresponse_types
パラメーターで使用されるものと同じです。 - 6
- この認可サーバーがサポートする OAuth 2.0 grant type の値の一覧が含まれる JSON 配列です。使用される配列の値は、RFC 7591 の OAuth 2.0 Dynamic Client Registration Protocol で定義される
grant_types
パラメーターで使用されるものと同じです。 - 7
- この認可サーバーでサポートされる PKCE RFC 7636 コードのチャレンジメソッドの一覧が含まれる JSON 配列です。コード のチャレンジメソッドの値は、RFC 7636 のセクション 4.3 で定義される
code_challenge_method
パラメーターで使用されます。有効なコードのチャレンジメソッドの値は、IANA PKCE Code Challenge Method レジストリーで登録される値です。IANA OAuth パラメーター を参照してください。
4.1.4.6. OAuth トークンの取得 リンクのコピーリンクがクリップボードにコピーされました!
OAuth サーバーは、標準的な Authorization Code Grant (認可コードによるグラント) および Implicit Grant (暗黙的グラント) の OAuth 認証フローをサポートします。
以下のコマンドを実行し、Authorization Code Grant (認可コードによるグラント) 方法を使用して OAuth トークンを要求します。
curl -H "X-Remote-User: <username>" \ --cacert /etc/origin/master/ca.crt \ --cert /etc/origin/master/admin.crt \ --key /etc/origin/master/admin.key \ -I https://<master-address>/oauth/authorize?response_type=token\&client_id=openshift-challenging-client | grep -oP "access_token=\K[^&]*"
$ curl -H "X-Remote-User: <username>" \
--cacert /etc/origin/master/ca.crt \
--cert /etc/origin/master/admin.crt \
--key /etc/origin/master/admin.key \
-I https://<master-address>/oauth/authorize?response_type=token\&client_id=openshift-challenging-client | grep -oP "access_token=\K[^&]*"
OAuth トークンを、(openshift-challenging-client
などの) WWW-Authenticate チャレンジ
を要求するように設定された client_id で Implicit Grant (暗黙的グラント) フロー (response_type=token
) を使用して要求する場合、以下が /oauth/authorize
から送られる可能性のあるサーバー応答、およびそれらの処理方法になります。
ステータス | 内容 | クライアント応答 |
---|---|---|
302 |
URL フラグメントに |
|
302 |
|
失敗します。 オプションで |
302 |
他の | これらのルールを使用してリダイレクトに従い、結果を処理します。 |
401 |
|
タイプ ( |
401 |
| チャレンジの認証ができません。失敗し、応答本体を表示します (これには、OAuth トークンを取得する別の方法についてのリンクまたは詳細が含まれる可能性があります) |
その他 | その他 | 失敗し、オプションでユーザーに応答本体を提示します。 |
Implicit Grant (暗黙的グラント) フローを使用して OAuth トークンを要求するには、以下を実行します。
curl -u <username>:<password>
$ curl -u <username>:<password>
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' -skv /
/ -H "X-CSRF-Token: xxx"
出力例
OAuth トークンの値のみを表示するには、以下のコマンドを実行します。
curl -u <username>:<password> /
$ curl -u <username>:<password> /
'https://<master-address>:8443/oauth/authorize?client_id=openshift-challenging-client&response_type=token' /
-skv -H "X-CSRF-Token: xxx" --stderr - | grep -oP "access_token=\K[^&]*"
出力例
hvqxe5aMlAzvbqfM2WWw3D6tR0R2jCQGKx0viZBxwmc
hvqxe5aMlAzvbqfM2WWw3D6tR0R2jCQGKx0viZBxwmc
トークンを要求するために Code Grant
方法を使用することもできます。
4.1.4.7. Prometheus の認証メトリクス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は認証の試行中に以下の Prometheus システムメトリクスをキャプチャーします。
-
openshift_auth_basic_password_count
はoc login
ユーザー名およびパスワードの試行回数をカウントします。 -
openshift_auth_basic_password_count_result
はoc login
ユーザー名および結果 (成功またはエラー) で試行されるパスワードの回数をカウントします。 -
openshift_auth_form_password_count
は Web コンソールのログイン試行回数をカウントします。 -
openshift_auth_form_password_count_result
は結果 (成功またはエラー) による Web コンソールのログイン試行回数をカウントします。 -
openshift_auth_password_total
はoc login
および Web コンソールのログイン試行回数をカウントします。