2.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
仮想グループを要求に割り当てます。これにより、認可層は匿名ユーザーが実行できる要求 (ある場合) を決定できます。
2.3.1. OpenShift Container Platform OAuth サーバー
OpenShift Container Platform マスターには、組み込まれた OAuth サーバーが含まれます。ユーザーは OAuth アクセストークンを取得して、API に対して認証します。
新しい OAuth のトークンが要求されると、OAuth サーバーは設定済みのアイデンティティプロバイダーを使用して要求したユーザーのアイデンティティーを判別します。
次に、そのアイデンティティーがマップするユーザーを判別し、そのユーザーのアクセストークンを作成し、そのトークンを使用できるように返します。
2.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
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
からトークンを手動で取得する必要があります。
2.3.1.2. API の権限借用
OpenShift Container Platform API への要求を、別のユーザーから発信されているかのように設定できます。詳細は、Kubernetes ドキュメントの User impersonation を参照してください。
2.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 コンソールのログイン試行回数をカウントします。