7.5. 要求ヘッダーアイデンティティープロバイダーの設定
request-header
アイデンティティープロバイダーを、X-Remote-User
などの要求ヘッダー値から識別するように設定します。通常、これは要求ヘッダー値を設定する認証プロキシーと併用されます。
7.5.1. OpenShift Container Platform のアイデンティティープロバイダーについて
デフォルトでは、kubeadmin
ユーザーのみがクラスターに存在します。アイデンティティープロバイダーを指定するには、アイデンティティープロバイダーを記述し、これをクラスターに追加するカスタムリソースを作成する必要があります。
/
、:
、および %
を含む OpenShift Container Platform ユーザー名はサポートされません。
7.5.2. 要求ヘッダー認証について
要求ヘッダーアイデンティティープロバイダーは、X-Remote-User
などの要求ヘッダー値からユーザーを識別します。通常、これは要求ヘッダー値を設定する認証プロキシーと併用されます。要求ヘッダーのアイデンティティープロバイダーは、htpasswd、Keystone、LDAP、Basic 認証などの直接パスワードログインを使用する他のアイデンティティープロバイダーと組み合わせることはできません。
さらに、コミュニティーでサポートされる SAML 認証 などの詳細な設定に要求ヘッダーアイデンティティープロバイダーを使用できます。このソリューションは Red Hat ではサポートされていないことに注意してください。
ユーザーがこのアイデンティティープロバイダーを使用して認証を行うには、認証プロキシー経由で https://<namespace_route>/oauth/authorize
(およびサブパス) にアクセスする必要があります。これを実行するには、OAuth トークンに対する非認証の要求を https://<namespace_route>/oauth/authorize
にプロキシー処理するプロキシーエンドポイントにリダイレクトするよう OAuth サーバーを設定します。
ブラウザーベースのログインフローが想定されるクライアントからの非認証要求をリダイレクトするには、以下を実行します。
-
provider.loginURL
パラメーターをインタラクティブなクライアントを認証する認証プロキシー URL に設定してから、要求をhttps://<namespace_route>/oauth/authorize
にプロキシーします。
WWW-Authenticate
チャレンジが想定されるクライアントからの非認証要求をリダイレクトするには、以下を実行します。
-
provider.challengeURL
パラメーターをWWW-Authenticate
チャレンジが予想されるクライアントを認証する認証プロキシー URL に設定し、要求をhttps://<namespace_route>/oauth/authorize
にプロキシーします。
provider.challengeURL
および provider.loginURL
パラメーターには、URL のクエリー部分に以下のトークンを含めることができます。
${url}
は現在の URL と置き換えられ、エスケープされてクエリーパラメーターで保護されます。例:
https://www.example.com/sso-login?then=${url}
${query}
は最新のクエリー文字列と置き換えられ、エスケープされません。例:
https://www.example.com/auth-proxy/oauth/authorize?${query}
OpenShift Container Platform 4.1 の時点で、プロキシーは相互 TLS をサポートしている必要があります。
7.5.2.1. Microsoft Windows での SSPI 接続サポート
Microsoft Windows での SSPI 接続サポートの使用はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポートについての詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
OpenShift CLI (oc
) は、Microsoft Windows での SSO フローを許可するために Security Support Provider Interface (SSPI) をサポートします。要求ヘッダーのアイデンティティープロバイダーを GSSAPI 対応プロキシーと共に使用して Active Directory サーバーを OpenShift Container Platform に接続する場合、ユーザーは、ドメイン参加済みの Microsoft Windows コンピューターから oc
コマンドラインインターフェイスを使用して OpenShift Container Platform に対して自動的に認証されます。
7.5.3. 設定マップの作成
アイデンティティープロバイダーは、openshift-config
namespace で OpenShift Container Platform ConfigMap
オブジェクトを使用し、認証局バンドルをこれに組み込みます。これらは、主にアイデンティティープロバイダーで必要な証明書バンドルを組み込むために使用されます。
手順
以下のコマンドを使用して、認証局が含まれる OpenShift Container Platform
ConfigMap
オブジェクトを定義します。認証局はConfigMap
オブジェクトのca.crt
キーに保存する必要があります。$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config
ヒントまたは、以下の YAML を適用して設定マップを作成できます。
apiVersion: v1 kind: ConfigMap metadata: name: ca-config-map namespace: openshift-config data: ca.crt: | <CA_certificate_PEM>
7.5.4. 要求ヘッダー CR のサンプル
以下のカスタムリソース (CR) は、要求ヘッダーアイデンティティープロバイダーのパラメーターおよび許可される値を示します。
要求ヘッダー CR
apiVersion: config.openshift.io/v1 kind: OAuth metadata: name: cluster spec: identityProviders: - name: requestheaderidp 1 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
- 1
- このプロバイダー名は要求ヘッダーのユーザー名に接頭辞として付加され、アイデンティティー名が作成されます。
- 2
- このプロバイダーのアイデンティティーと
User
オブジェクト間にマッピングが確立される方法を制御します。 - 3
- オプション: 非認証の
/oauth/authorize
要求のリダイレクト先となる URL です。これは、ブラウザーベースのクライアントを認証し、その要求をhttps://<namespace_route>/oauth/authorize
にプロキシーします。https://<namespace_route>/oauth/authorize
にプロキシーする URL は/authorize
(末尾にスラッシュはない) で終了し、OAuth 承認フローが適切に機能するようにサブパスもプロキシーする必要があります。${url}
は現在の URL と置き換えられ、エスケープされてクエリーパラメーターで保護されます。${query}
は最新のクエリー文字列と置き換えられます。この属性が定義されない場合は、loginURL
が使用される必要があります。 - 4
- オプション: 非認証の
/oauth/authorize
要求のリダイレクト先となる URL です。これにより、WWW-Authenticate
チャレンジが予想されるクライアントの認証が行われ、それらの要求がhttps://<namespace_route>/oauth/authorize
にプロキシーされます。${url}
は現在の URL と置き換えられ、エスケープされてクエリーパラメーターで保護されます。${query}
は最新のクエリー文字列と置き換えられます。この属性が定義されない場合は、challengeURL
が使用される必要があります。 - 5
- PEM エンコードされた証明書バンドルを含む OpenShift Container Platform
ConfigMap
オブジェクトへの参照。リモートサーバーによって表示される TLS 証明書を検証するためにトラストアンカーとして使用されます。重要OpenShift Container Platform 4.1 の時点で、
ca
フィールドはこのアイデンティティープロバイダーに必要です。これは、プロキシーが相互 TLS をサポートしている必要があることを意味します。 - 6
- オプション: 共通名 (
cn
) の一覧。これが設定されている場合は、要求ヘッダーのユーザー名をチェックする前に指定される一覧の Common Name (cn
) を持つ有効なクライアント証明書が提示される必要があります。空の場合、すべての Common Name が許可されます。これはca
と組み合わせる場合にのみ使用できます。 - 7
- ユーザーアイデンティティーを順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーはアイデンティティーとして使用されます。これは必須であり、大文字小文字を区別します。
- 8
- メールアドレスを順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーはメールアドレスとして使用されます。これは任意であり、大文字小文字を区別します。
- 9
- 表示名を順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーは表示名として使用されます。これは任意であり、大文字小文字を区別します。
- 10
- 推奨ユーザー名を順番にチェックする際に使用するヘッダー名 (
headers
に指定されるヘッダーで決定される変更不可のアイデンティティーと異なる場合)。値を含む最初のヘッダーは、プロビジョニング時に推奨ユーザー名として使用されます。これは任意であり、大文字小文字を区別します。
関連情報
-
すべてのアイデンティティープロバイダーに共通するパラメーターの詳細は、アイデンティティープロバイダーのパラメーター (
mappingMethod
など) について参照してください。
7.5.5. アイデンティティープロバイダーのクラスターへの追加
クラスターのインストール後に、アイデンティティープロバイダーをそのクラスターに追加し、ユーザーの認証を実行できるようにします。
前提条件
- OpenShift Container Platform クラスターを作成します。
- アイデンティティープロバイダーのカスタムリソース (CR) を作成します。
- 管理者としてログインしている必要があります。
手順
定義された CR を適用します。
$ oc apply -f </path/to/CR>
注記CR が存在しない場合、
oc apply
は新規 CR を作成し、さらに以下の警告をトリガーする可能性があります。Warning: oc apply should be used on resources created by either oc create --save-config or oc apply
この場合は、この警告を無視しても問題ありません。アイデンティティープロバイダーのユーザーとしてクラスターにログインし、プロンプトが出されたらパスワードを入力します。
$ oc login -u <username>
ユーザーが正常にログインされていることを確認し、ユーザー名を表示します。
$ oc whoami
7.5.6. 要求ヘッダーを使用した Apache 認証設定の例
この例では、要求ヘッダーアイデンティティープロバイダーを使用して OpenShift Container Platform の Apache 認証プロキシーを設定します。
カスタムプロキシー設定
mod_auth_gssapi
モジュールの使用は、要求ヘッダーアイデンティティープロバイダーを使用して Apache 認証プロキシーを設定する一般的な方法ですが、必須の方法ではありません。以下の要件を満たすと、他のプロキシーを簡単に使用できます。
-
クライアント要求の
X-Remote-User
ヘッダーをブロックして、スプーフィングを防ぎます。 -
RequestHeaderIdentityProvider
設定でクライアント証明書の認証を適用します。 -
チャレンジフローを使用してすべての認証要求についての
X-Csrf-Token
ヘッダーを設定する必要があります。 -
/oauth/authorize
エンドポイントとそのサブパスのみがプロキシーされる必要があります。バックエンドサーバーがクライアントを正しい場所に送信できるようリダイレクトは書き換える必要があります。 -
https://<namespace_route>/oauth/authorize
にプロキシーする URL は/authorize
で終了 (末尾のスラッシュなし) する必要があります。たとえば、https://proxy.example.com/login-proxy/authorize?…
は、https://<namespace_route>/oauth/authorize?…
にプロキシーする必要があります。 -
https://<namespace_route>/oauth/authorize
にプロキシーされる URL のサブパスは、https://<namespace_route>/oauth/authorize
にプロキシーする必要があります。たとえば、https://proxy.example.com/login-proxy/authorize/approve?…
は、https://<namespace_route>/oauth/authorize/approve?…
にプロキシーする必要があります。
https://<namespace_route>
アドレスは OAuth サーバーへのルートであり、oc get route -n openshift-authentication
を実行して取得できます。
要求ヘッダーを使用した Apache 認証の設定
この例では、mod_auth_gssapi
モジュールを使用し、要求ヘッダーアイデンティティープロバイダーを使用して Apache 認証プロキシーを設定します。
前提条件
mod_auth_gssapi
モジュールを Optional チャンネル から取得します。ローカルマシンに以下のパッケージをインストールする必要があります。-
httpd
-
mod_ssl
-
mod_session
-
apr-util-openssl
-
mod_auth_gssapi
-
信頼されたヘッダーを送信する要求を検証するために CA を生成します。CA を含む OpenShift Container Platform
ConfigMap
オブジェクトを定義します。これは、以下を実行して行います。$ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config 1
- 1
- CA は、
ConfigMap
オブジェクトのca.crt
キーに保存する必要があります。
ヒントまたは、以下の YAML を適用して設定マップを作成できます。
apiVersion: v1 kind: ConfigMap metadata: name: ca-config-map namespace: openshift-config data: ca.crt: | <CA_certificate_PEM>
- このプロキシー用のクライアント証明書を生成します。この証明書は、x509 証明書ツールを使用して生成できます。信頼されたヘッダーを送信する要求を検証するために、生成した CA でクライアント証明書に署名する必要があります。
- アイデンティティープロバイダーのカスタムリソース (CR) を作成します。
手順
このプロキシーはクライアント証明書を使用して OAuth サーバーに接続します。これは、X-Remote-User
ヘッダーを信頼するように設定されます。
-
Apache 設定の証明書を作成します。
SSLProxyMachineCertificateFile
パラメーターの値として指定する証明書は、プロキシーをサーバーに対して認証するために使用されるプロキシーのクライアント証明書です。これは、拡張されたキーのタイプとしてTLS Web Client Authentication
を使用する必要があります。 Apache 設定を作成します。以下のテンプレートを使用して必要な設定および値を指定します。
重要テンプレートを十分に確認し、その内容を環境に合うようにカスタマイズします。
LoadModule request_module modules/mod_request.so LoadModule auth_gssapi_module modules/mod_auth_gssapi.so # Some Apache configurations might require these modules. # LoadModule auth_form_module modules/mod_auth_form.so # LoadModule session_module modules/mod_session.so # Nothing needs to be served over HTTP. This virtual host simply redirects to # HTTPS. <VirtualHost *:80> DocumentRoot /var/www/html RewriteEngine On RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R,L] </VirtualHost> <VirtualHost *:443> # This needs to match the certificates you generated. See the CN and X509v3 # Subject Alternative Name in the output of: # openssl x509 -text -in /etc/pki/tls/certs/localhost.crt ServerName www.example.com DocumentRoot /var/www/html SSLEngine on SSLCertificateFile /etc/pki/tls/certs/localhost.crt SSLCertificateKeyFile /etc/pki/tls/private/localhost.key SSLCACertificateFile /etc/pki/CA/certs/ca.crt SSLProxyEngine on SSLProxyCACertificateFile /etc/pki/CA/certs/ca.crt # It is critical to enforce client certificates. Otherwise, requests can # spoof the X-Remote-User header by accessing the /oauth/authorize endpoint # directly. SSLProxyMachineCertificateFile /etc/pki/tls/certs/authproxy.pem # To use the challenging-proxy, an X-Csrf-Token must be present. RewriteCond %{REQUEST_URI} ^/challenging-proxy RewriteCond %{HTTP:X-Csrf-Token} ^$ [NC] RewriteRule ^.* - [F,L] <Location /challenging-proxy/oauth/authorize> # Insert your backend server name/ip here. ProxyPass https://<namespace_route>/oauth/authorize AuthName "SSO Login" # For Kerberos AuthType GSSAPI Require valid-user RequestHeader set X-Remote-User %{REMOTE_USER}s GssapiCredStore keytab:/etc/httpd/protected/auth-proxy.keytab # Enable the following if you want to allow users to fallback # to password based authentication when they do not have a client # configured to perform kerberos authentication. GssapiBasicAuth On # For ldap: # AuthBasicProvider ldap # AuthLDAPURL "ldap://ldap.example.com:389/ou=People,dc=my-domain,dc=com?uid?sub?(objectClass=*)" </Location> <Location /login-proxy/oauth/authorize> # Insert your backend server name/ip here. ProxyPass https://<namespace_route>/oauth/authorize AuthName "SSO Login" AuthType GSSAPI Require valid-user RequestHeader set X-Remote-User %{REMOTE_USER}s env=REMOTE_USER GssapiCredStore keytab:/etc/httpd/protected/auth-proxy.keytab # Enable the following if you want to allow users to fallback # to password based authentication when they do not have a client # configured to perform kerberos authentication. GssapiBasicAuth On ErrorDocument 401 /login.html </Location> </VirtualHost> RequestHeader unset X-Remote-User
注記https://<namespace_route>
アドレスは OAuth サーバーへのルートであり、oc get route -n openshift-authentication
を実行して取得できます。カスタムリソース (CR) の
identityProviders
スタンザを更新します。identityProviders: - name: requestheaderidp type: RequestHeader requestHeader: challengeURL: "https://<namespace_route>/challenging-proxy/oauth/authorize?${query}" loginURL: "https://<namespace_route>/login-proxy/oauth/authorize?${query}" ca: name: ca-config-map clientCommonNames: - my-auth-proxy headers: - X-Remote-User
設定を確認します。
適切なクライアント証明書およびヘッダーを指定して、トークンを要求し、プロキシーをバイパスできることを確認します。
# curl -L -k -H "X-Remote-User: joe" \ --cert /etc/pki/tls/certs/authproxy.pem \ https://<namespace_route>/oauth/token/request
クライアント証明書を提供しない要求が、証明書なしでトークンを要求して失敗することを確認します。
# curl -L -k -H "X-Remote-User: joe" \ https://<namespace_route>/oauth/token/request
challengeURL
リダイレクトがアクティブであることを確認します。# curl -k -v -H 'X-Csrf-Token: 1' \ https://<namespace_route>/oauth/authorize?client_id=openshift-challenging-client&response_type=token
以下の手順で使用する
challengeURL
リダイレクトをコピーします。このコマンドを実行して、
WWW-Authenticate
基本チャレンジ、ネゴシエートチャレンジ、またはそれらの両方のチャレンジを含む401
応答を表示します。# curl -k -v -H 'X-Csrf-Token: 1' \ <challengeURL_redirect + query>
Kerberos チケットを使用または使用せずに、OpenShift CLI (
oc
) へのログインをテストします。kinit
を使用して Kerberos チケットを生成した場合は、これを破棄します。# kdestroy -c cache_name 1
- 1
- Kerberos キャッシュの名前を指定します。
Kerberos 認証情報を使用して
oc
ツールにログインします。# oc login -u <username>
プロンプトで、Kerberos パスワードを入力します。
oc
ツールからログアウトします。# oc logout
Kerberos 認証情報を使用してチケットを取得します。
# kinit
プロンプトで、Kerberos ユーザー名およびパスワードを入力します。
oc
ツールにログインできることを確認します。# oc login
設定が正しい場合は、別の認証情報を入力せずにログインできます。