要求ヘッダー CR のサンプル

以下のカスタムリソース (CR) は、要求ヘッダーアイデンティティープロバイダーのパラメーターおよ び許可される値を示します。

要求ヘッダー 要求ヘッダー CR

$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config

apiVersion: config.openshift.io/v1 kind: OAuth

metadata:

name: cluster spec:

identityProviders:

- name: requestheaderidp 1

1

2

3

4

5

6

このプロバイダー名は要求ヘッダーのユーザー名にプレフィックスとして付加され、アイデンティ ティー名が作成されます。

このプロバイダーのアイデンティティーと User オブジェクト間にマッピングが確立される方法を 制御します。

オプション: 非認証の /oauth/authorize 要求のリダイレクト先となる URL です。これは、ブラウ ザーベースのクライアントを認証し、その要求を https://<namespace_route>/oauth/authorize にプロキシーします。https://<namespace_route>/oauth/authorize にプロキシーする URL は /authorize (末尾にスラッシュはない) で終了し、OAuth 承認フローが適切に機能するようにサブ パスもプロキシーする必要があります。${url} は現在の URL と置き換えられ、エスケープされて クエリーパラメーターで保護されます。${query} は最新のクエリー文字列と置き換えられます。

この属性が定義されない場合は、loginURL が使用される必要があります。

オプション: 非認証の /oauth/authorize 要求のリダイレクト先となる URL です。これによ

り、WWW-Authenticate チャレンジが予想されるクライアントの認証が行われ、それらの要求が

https://<namespace_route>/oauth/authorize にプロキシーされます。${url} は現在の URL と置 き換えられ、エスケープされてクエリーパラメーターで保護されます。${query} は最新のクエ リー文字列と置き換えられます。この属性が定義されない場合は、 challengeURL が使用される 必要があります。

PEM エンコードされた証明書バンドルを含む OpenShift Container Platform ConfigMap オブジェ クトへの参照。リモートサーバーによって表示される TLS 証明書を検証するためにトラストアン カーとして使用されます。

重要 重要

OpenShift Container Platform 4.1 の時点で、ca フィールドはこのアイデンティ ティープロバイダーに必要です。これは、プロキシーが相互 TLS をサポートしてい る必要があることを意味します。

オプション: 共通名 (cn) の一覧。これが設定されている場合は、要求ヘッダーのユーザー名を チェックする前に指定される一覧の Common Name (cn) を持つ有効なクライアント証明書が提示 される必要があります。空の場合、すべての Common Name が許可されます。これは caと組み合 わせる場合にのみ使用できます。

mappingMethod: claim 2 type: RequestHeader requestHeader:

challengeURL: "https://www.example.com/challenging-proxy/oauth/authorize?${query}" 3 loginURL: "https://www.example.com/login-proxy/oauth/authorize?${query}" 4

ca: 5

name: ca-config-map clientCommonNames: 6 - my-auth-proxy

headers: 7 - X-Remote-User - SSO-User emailHeaders: 8 - X-Remote-User-Email nameHeaders: 9

- X-Remote-User-Display-Name preferredUsernameHeaders: 10 - X-Remote-User-Login

7

8

9

10

ユーザーアイデンティティーを順番にチェックする際に使用するヘッダー名。値を含む最初のヘッ ダーはアイデンティティーとして使用されます。これは必須であり、大文字小文字を区別します。

メールアドレスを順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーはメール アドレスとして使用されます。これは任意であり、大文字小文字を区別します。

表示名を順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーは表示名として使 用されます。これは任意であり、大文字小文字を区別します。

推奨ユーザー名を順番にチェックする際に使用するヘッダー名 ( headers に指定されるヘッダーで 決定される変更不可のアイデンティティーと異なる場合)。値を含む最初のヘッダーは、プロビ ジョニング時に推奨ユーザー名として使用されます。これは任意であり、大文字小文字を区別しま す。

追加リソース 追加リソース

すべてのアイデンティティープロバイダーに共通するパラメーターの詳細は、アイデンティ ティープロバイダーのパラメーター（（mappingMethod など）について参照してください。

6.5.5. アイデンティティープロバイダーのクラスターへの追加

クラスターのインストール後に、アイデンティティープロバイダーをそのクラスターに追加し、ユー ザーの認証を実行できるようにします。

前提条件 前提条件

OpenShift Container Platform クラスターを作成します。

アイデンティティープロバイダーのカスタムリソース (CR) を作成します。

管理者としてログインしている必要があります。

手順 手順

1. 定義された CR を適用します。

注記 注記

CR が存在しない場合、oc apply は新規 CR を作成し、さらに以下の警告をトリ ガーする可能性があります。Warning: oc apply should be used on resources created by either oc create --save-config or oc applyこの場合は、この警告を 無視しても問題ありません。

2. アイデンティティープロバイダーのユーザーとしてクラスターにログインし、プロンプトが出 されたらパスワードを入力します。

3. ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。

$ oc apply -f </path/to/CR>

$ oc login -u <username>

$ oc whoami