Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

13.3.9. 要求ヘッダー

identityProviders スタンザで RequestHeaderIdentityProvider を設定して、X-Remote-User などの要求ヘッダー値からユーザーを識別します。これは通常、プロキシー認証と組み合わせて使用され、要求ヘッダー値を設定します。これは OpenShift Enterprise 2 のリモートユーザープラグイン によって管理者が Kerberos、LDAP、その他の数多くの形式のエンタープライズ認証を指定する方法と似ています。

注記

さらに、コミュニティーでサポートされる SAML 認証 などの詳細な設定に要求ヘッダーアイデンティティープロバイダーを使用できます。SAML 認証は Red Hat ではサポートされていないことに注意してください。

ユーザーがこのアイデンティティープロバイダーを使用して認証を行うには、認証プロキシー経由で https://<master>/oauth/authorize (およびサブパス) にアクセスする必要があります。これを実行するには、OAuth トークンに対する非認証の要求を https://<master>/oauth/authorize にプロキシー処理するプロキシーエンドポイントにリダイレクトするよう OAuth サーバーを設定します。

ブラウザーベースのログインフローが想定されるクライアントからの非認証要求をリダイレクトするには、以下を実行します。

  1. login パラメーターを true に設定します。
  2. provider.loginURL パラメーターをインタラクティブなクライアントを認証する認証プロキシー URL に設定してから、要求を https://<master>/oauth/authorize にプロキシーします。

WWW-Authenticate チャレンジが想定されるクライアントからの非認証要求をリダイレクトするには、以下を実行します。

  1. challenge パラメーターを true に設定します。
  2. provider.challengeURL パラメーターを WWW-Authenticate チャレンジが予想されるクライアントを認証する認証プロキシー URL に設定し、要求を https://<master>/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}

警告

非認証要求が OAuth サーバーに到達することを想定する場合は、要求ヘッダーのユーザー名がチェックされる前に受信要求の有効なクライアント証明書をチェックするように、clientCA パラメーターをこのアイデンティティープロバイダーに対して設定する必要があります。これを設定しない場合、OAuth サーバーへの直接的な要求は、要求ヘッダーを設定するだけでこのプロバイダーのアイデンティティーになりすます可能性があります。

RequestHeaderIdentityProvider を使用したマスター設定

oauthConfig:
  ...
  identityProviders:
  - name: my_request_header_provider
1 

    challenge: true
2 

    login: true
3 

    mappingMethod: claim
4 

    provider:
      apiVersion: v1
      kind: RequestHeaderIdentityProvider
      challengeURL: "https://www.example.com/challenging-proxy/oauth/authorize?${query}"
5 

      loginURL: "https://www.example.com/login-proxy/oauth/authorize?${query}"
6 

      clientCA: /path/to/client-ca.file
7 

      clientCommonNames:
8 

      - my-auth-proxy
      headers:
9 

      - X-Remote-User
      - SSO-User
      emailHeaders:
10 

      - X-Remote-User-Email
      nameHeaders:
11 

      - X-Remote-User-Display-Name
      preferredUsernameHeaders:
12 

      - X-Remote-User-Login
Copy to Clipboard Toggle word wrap

1
このプロバイダー名は要求ヘッダーのユーザー名に接頭辞として付加され、アイデンティティー名が作成されます。
2
RequestHeaderIdentityProvider は、設定された challengeURL にリダイレクトすることで、WWW-Authenticate チャレンジを要求するクライアントに応答します。設定された URL は WWW-Authenticate チャレンジを使用して応答します。
3
RequestHeaderIdentityProvider は、設定された loginURL にリダイレクトすることで、ログインフローを要求するクライアントにのみ応答できます。設定される URL はログインフローを使用して応答します。
4
このプロバイダーのアイデンティティーとユーザーオブジェクト間のマッピングの確立方法を制御します (上記 を参照してください)。
5
オプション: 非認証の /oauth/authorize 要求のリダイレクト先となる URL です。これにより、WWW-Authenticate チャレンジが予想されるクライアントの認証が行われ、それらの要求が https://<master>/oauth/authorize にプロキシーされます。${url} は現在の URL と置き換えられ、エスケープされてクエリーパラメーターで保護されます。${query} は最新のクエリー文字列と置き換えられます。
6
オプション: 非認証の /oauth/authorize 要求のリダイレクト先となる URL です。これは、ブラウザーベースのクライアントを認証してから、その要求を https://<master>/oauth/authorize にプロキシー化します。https://<master>/oauth/authorize にプロキシーする URL は /authorize (末尾にスラッシュはない) で終了し、OAuth 承認フローが適切に機能するようにサブパスもプロキシーする必要があります。${url} は現在の URL と置き換えられ、エスケープされてクエリーパラメーターで保護されます。${query} は最新のクエリー文字列と置き換えられます。
7
オプション: PEM でエンコードされた証明書バンドルです。これが設定されている場合、要求ヘッダーのユーザー名をチェックする前に、有効なクライアント証明書が提示され、指定ファイルで認証局に対して検証される必要があります。
8
オプション: 共通名 (cn) の一覧。これが設定されている場合は、要求ヘッダーのユーザー名をチェックする前に指定される一覧の Common Name (cn) を持つ有効なクライアント証明書が提示される必要があります。空の場合、すべての Common Name が許可されます。これは clientCA との組み合わせる場合にのみ使用できます。
9
ユーザーアイデンティティーを順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーはアイデンティティーとして使用されます。これは必須であり、大文字小文字を区別します。
10
メールアドレスを順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーはメールアドレスとして使用されます。これは任意であり、大文字小文字を区別します。
11
表示名を順番にチェックする際に使用するヘッダー名。値を含む最初のヘッダーは表示名として使用されます。これは任意であり、大文字小文字を区別します。
12
推奨ユーザー名を順番にチェックする際に使用するヘッダー名 ( headers に指定されるヘッダーで決定される変更不可のアイデンティティーと異なる場合)。値を含む最初のヘッダーは、プロビジョニング時に推奨ユーザー名として使用されます。これは任意であり、大文字小文字を区別します。
Microsoft Windows での SSPI 接続サポート
重要

Microsoft Windows での SSPI 接続サポートの使用はテクノロジープレビュー機能です。テクノロジープレビュー機能は Red Hat の実稼働環境でのサービスレベルアグリーメント (SLA) ではサポートされていないため、Red Hat では実稼働環境での使用を推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポートについての詳細は、https://access.redhat.com/support/offerings/techpreview/ を参照してください。

バージョン 3.11 以降

oc は、Microsoft Windows での SSO フローを許可するために Security Support Provider Interface (SSPI) をサポートします。要求ヘッダーのアイデンティティープロバイダーを GSSAPI 対応プロキシーと共に使用して Active Directory サーバーを OpenShift Container Platform に接続する場合、ユーザーは、ドメイン参加済みの Microsoft Windows コンピューターから oc コマンドラインインターフェイスを使用して OpenShift Container Platform に対して自動的に認証されます。

要求ヘッダーを使用した Apache 認証

この例は、マスターと同じホストに認証プロキシーを設定しています。同じホストにプロキシーとマスターがあると便利ですが、ご使用中の環境に適さない場合があります。たとえば、すでにマスターで ルーターを実行 している場合、ポート 443 が利用できなくなります。

この参照設定は Apache の mod_auth_gssapi を使用していますが、これは決して必須ではなく、以下の要件を満たしていれば他のプロキシーを簡単に使用することができます。

  1. クライアント要求の X-Remote-User ヘッダーをブロックして、スプーフィングを防ぎます。
  2. RequestHeaderIdentityProvider 設定でクライアント証明書の認証を適用します。
  3. チャレンジフローを使用してすべての認証要求についての X-Csrf-Token ヘッダーを設定する必要があります。
  4. /oauth/authorize エンドポイントとそのサブパスのみがプロキシーされる必要があります。 バックエンドサーバーがクライアントを正しい場所へ送信できるようリダイレクトは書き換えないでください。

  5. https://<master>/oauth/authorize へプロキシーする URL は /authorize で終了 (末尾のスラッシュなし) する必要があります。以下に例を示します。

    • https://proxy.example.com/login-proxy/authorize?…​ https://<master>/oauth/authorize?…​

  6. https://<master>/oauth/authorize にプロキシーされる URL のサブパスは、https://<master>/oauth/authorize のサブパスにプロキシーする必要があります。以下に例を示します。

    • https://proxy.example.com/login-proxy/authorize/approve?…​ https://<master>/oauth/authorize/approve?…​
前提条件のインストール

  1. mod_auth_gssapi モジュールを Optional チャンネル から取得します。以下のパッケージをインストールします。 

    # yum install -y httpd mod_ssl mod_session apr-util-openssl mod_auth_gssapi
    Copy to Clipboard Toggle word wrap

  2. 信頼されたヘッダーを送信する要求を検証するために CA を生成します。この CA は マスターのアイデンティティープロバイダーの設定 の clientCA のファイル名として使用されます。 

    # oc adm ca create-signer-cert \
  --cert='/etc/origin/master/proxyca.crt' \
  --key='/etc/origin/master/proxyca.key' \
  --name='openshift-proxy-signer@1432232228' \
  --serial='/etc/origin/master/proxyca.serial.txt'
    Copy to Clipboard Toggle word wrap
    注記

    oc adm ca create-signer-cert コマンドは、5 年間有効な証明書を生成します。この期間は --expire-days オプションを使って変更することができますが、セキュリティー上の理由から、値をこれより大きくすることは推奨されません。

    Ansible ホストインベントリーファイル (デフォルトで /etc/ansible/hosts) に最初に一覧表示されているマスターから oc adm コマンドを実行します。

  3. このプロキシー用のクライアント証明書を生成します。x509 証明書ツーリングを使用して実行することができます。oc adm CLI を使用すると便利です。 

    # oc adm create-api-client-config \
  --certificate-authority='/etc/origin/master/proxyca.crt' \
  --client-dir='/etc/origin/master/proxy' \
  --signer-cert='/etc/origin/master/proxyca.crt' \
  --signer-key='/etc/origin/master/proxyca.key' \
  --signer-serial='/etc/origin/master/proxyca.serial.txt' \
  --user='system:proxy'
    1 
    

# pushd /etc/origin/master
# cp master.server.crt /etc/pki/tls/certs/localhost.crt
    2 
    
# cp master.server.key /etc/pki/tls/private/localhost.key
# cp ca.crt /etc/pki/CA/certs/ca.crt
# cat proxy/system\:proxy.crt \
  proxy/system\:proxy.key > \
  /etc/pki/tls/certs/authproxy.pem
# popd
    Copy to Clipboard Toggle word wrap
    1
    ユーザー名は任意に指定できますが、ログにそのまま表示されるのでわかりやすい名前をつけると便利です。
    2
    マスターと異なるホスト名で認証プロキシーを実行する場合、上記のようにデフォルトのマスター証明書を使用するのではなく、ホスト名と一致する証明書を生成することが重要です。/etc/origin/master/master-config.yaml ファイルの masterPublicURL の値は、SSLCertificateFile に対して指定される証明書の X509v3 Subject Alternative Name に含まれる必要があります。新規の証明書を作成する必要がある場合は、oc adm ca create-server-cert コマンドを使用できます。
    注記

    oc adm create-api-client-config コマンドは、2 年間有効な証明書を生成します。この期間は --expire-days オプションを使って変更することができますが、セキュリティー上の理由から、値をこれより大きくすることは推奨されません。Ansible ホストインベントリーファイル (デフォルトで /etc/ansible/hosts) に最初に一覧表示されているマスターから oc adm コマンドを実行します。

Apache の設定

このプロキシーはマスターと同じホストにある必要はありません。これはクライアント証明書を使用してマスターに接続し、X-Remote-User ヘッダーを信頼するように設定されます。

  1. Apache 設定の証明書を作成します。SSLProxyMachineCertificateFile パラメーターの値として指定する証明書は、プロキシーをサーバーに対して認証するために使用されるプロキシーのクライアント証明書です。これは、拡張されたキーのタイプとして TLS Web Client Authentication を使用する必要があります。

  2. 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's critical to enforce client certificates on the Master.  Otherwise
  # requests could spoof the X-Remote-User header by accessing the Master's
  # /oauth/authorize endpoint directly.
  SSLProxyMachineCertificateFile /etc/pki/tls/certs/authproxy.pem

  # Send all requests to the console
  RewriteEngine              On
  RewriteRule     ^/console(.*)$     https://%{HTTP_HOST}:8443/console$1 [R,L]

  # In order to using 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://[MASTER]:8443/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 authntication 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=*)"

      # It's possible to remove the mod_auth_gssapi usage and replace it with
      # something like mod_auth_mellon, which only supports the login flow.
    </Location>

    <Location /login-proxy/oauth/authorize>
    # Insert your backend server name/ip here.
    ProxyPass https://[MASTER]:8443/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 authntication 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
    Copy to Clipboard Toggle word wrap
マスターの設定

/etc/origin/master/master-config.yaml ファイルの identityProviders スタンザも更新する必要があります。 

  identityProviders:
  - name: requestheader
    challenge: true
    login: true
    provider:
      apiVersion: v1
      kind: RequestHeaderIdentityProvider
      challengeURL: "https://[MASTER]/challenging-proxy/oauth/authorize?${query}"
      loginURL: "https://[MASTER]/login-proxy/oauth/authorize?${query}"
      clientCA: /etc/origin/master/proxyca.crt
      headers:
      - X-Remote-User
Copy to Clipboard Toggle word wrap
サービスの再起動

最後に、以下のサービスを再起動します。 

# systemctl restart httpd
# master-restart api
# master-restart controllers
Copy to Clipboard Toggle word wrap
設定の確認

  1. プロキシーをバイパスしてテストします。正しいクライアント証明書とヘッダーを指定すれば、トークンを要求できます。 

    # curl -L -k -H "X-Remote-User: joe" \
   --cert /etc/pki/tls/certs/authproxy.pem \
   https://[MASTER]:8443/oauth/token/request
    Copy to Clipboard Toggle word wrap

  2. クライアント証明書を指定しない場合、要求は拒否されます。 

    # curl -L -k -H "X-Remote-User: joe" \
   https://[MASTER]:8443/oauth/token/request
    Copy to Clipboard Toggle word wrap

  3. これは、設定された challengeURL (追加のクエリーパラメーターを含む) へのリダイレクトを示します。 

    # curl -k -v -H 'X-Csrf-Token: 1' \
   '<masterPublicURL>/oauth/authorize?client_id=openshift-challenging-client&response_type=token'
    Copy to Clipboard Toggle word wrap

  4. これにより、WWW-Authenticate 基本チャレンジ、ネゴシエートチャレンジ、またはそれらの両方のチャレンジを含む 401 応答が表示されるはずです。 

    #  curl -k -v -H 'X-Csrf-Token: 1' \
    '<redirected challengeURL from step 3 +query>'
    Copy to Clipboard Toggle word wrap

  5. Kerberos チケットを使用または使用せずに、oc コマンドラインへのログインをテストします。

    1. kinit を使用して Kerberos チケットを生成した場合は、これを破棄します。 

      # kdestroy -c cache_name
      1
      Copy to Clipboard Toggle word wrap
      1
      Kerberos キャッシュの名前を指定します。

    2. Kerberos 認証情報を使用して oc コマンドラインにログインします。 

      # oc login
      Copy to Clipboard Toggle word wrap

      プロンプトで、Kerberos ユーザー名およびパスワードを入力します。

    3. oc コマンドラインからログアウトします。 

      # oc logout
      Copy to Clipboard Toggle word wrap

    4. Kerberos 認証情報を使用してチケットを取得します。 

      # kinit
      Copy to Clipboard Toggle word wrap

      プロンプトで、Kerberos ユーザー名およびパスワードを入力します。

    5. oc コマンドラインにログインできることを確認します。 

      # oc login
      Copy to Clipboard Toggle word wrap

      設定が正しい場合は、別の認証情報を入力せずにログインできます。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat