This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.1.3. API 認証
OpenShift Container Platform API への要求は以下の方法で認証されます。
- OAuth アクセストークン
 - 
									
<namespace_route>/oauth/authorizeおよび<namespace_route>/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 仮想グループを要求に割り当てます。これにより、認可層は匿名ユーザーが実行できる要求 (ある場合) を決定できます。
			
1.3.1. OpenShift Container Platform OAuth サーバー リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform マスターには、組み込まれた OAuth サーバーが含まれます。ユーザーは OAuth アクセストークンを取得して、API に対して認証します。
新しいOAuthのトークンが要求されると、OAuth サーバーは設定済みのアイデンティティプロバイダーを使用して要求したユーザーのアイデンティティーを判別します。
次に、そのアイデンティティーがマップするユーザーを判別し、そのユーザーのアクセストークンを作成し、そのトークンを使用できるように返します。
1.3.1.1. OAuth トークン要求 リンクのコピーリンクがクリップボードにコピーされました!
OAuth トークンのすべての要求は、トークンを受信し、使用する OAuth クライアントを指定する必要があります。以下の OAuth クライアントは、OpenShift Container Platform API の起動時に自動的に作成されます。
| OAuth クライアント | 使用法 | 
|---|---|
|   
										  |   
										対話式ログインを処理できるユーザーエージェントで   | 
|   
										  |   
										  | 
<namespace_route> は namespace のルートを参照します。これは、以下のコマンドを実行して確認できます。
oc get route oauth-openshift -n openshift-authentication -o json | jq .spec.host
oc get route oauth-openshift -n openshift-authentication -o json | jq .spec.host
						OAuth トークンのすべての要求には <namespace_route>/oauth/authorize への要求が必要になります。ほとんどの認証統合では、認証プロキシーをこのエンドポイントの前に配置するか、または OpenShift Container Platform を、サポートするアイデンティティープロバイダーに対して認証情報を検証するように設定します。<namespace_route>/oauth/authorize の要求は、CLI などの対話式ログインページを表示できないユーザーエージェントから送られる場合があります。そのため、OpenShift Container Platform は、対話式ログインフローのほかにも WWW-Authenticate チャレンジを使用した認証をサポートします。
					
						認証プロキシーが <namespace_route>/oauth/authorize エンドポイントの前に配置される場合、対話式ログインページを表示したり、対話式ログインフローにリダイレクトする代わりに、認証されていない、ブラウザー以外のユーザーエージェントの WWW-Authenticate チャレンジを送信します。
					
							ブラウザークライアントに対するクロスサイトリクエストフォージェリー (CSRF) 攻撃を防止するため、基本的な認証チャレンジは X-CSRF-Token ヘッダーが要求に存在する場合にのみ送信されます。基本的な WWW-Authenticate チャレンジを受信する必要があるクライアントでは、このヘッダーを空でない値に設定する必要があります。
						
							認証プロキシーが WWW-Authenticate チャレンジをサポートしないか、または OpenShift Container Platform が WWW-Authenticate チャレンジをサポートしないアイデンティティープロバイダーを使用するように設定されている場合、ユーザーはブラウザーで <namespace_route>/oauth/token/request からトークンを手動で取得する必要があります。
						
1.3.1.2. API の権限借用 リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform API への要求を、別のユーザーから発信されているかのように設定できます。詳細は、Kubernetes ドキュメントの「User impersonation」を参照してください。
1.3.1.3. Prometheus の認証メトリクス リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Container Platform は認証の試行中に以下の Prometheus システムメトリクスをキャプチャーします。
- 
								
openshift_auth_basic_password_countはoc loginユーザー名およびパスワードの試行回数をカウントします。 - 
								
openshift_auth_basic_password_count_resultは、oc loginユーザー名およびパスワードの試行回数を結果 (successまたはerror) 別にカウントします。 - 
								
openshift_auth_form_password_countは Web コンソールのログイン試行回数をカウントします。 - 
								
openshift_auth_form_password_count_resultは結果 (successまたはerror) 別に Web コンソールのログイン試行回数をカウントします。 - 
								
openshift_auth_password_totalはoc loginおよび Web コンソールのログイン試行回数をカウントします。