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

4.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
    Copy to Clipboard Toggle word wrap

    CA は、ConfigMap オブジェクトの ca.crt キーに保存する必要があります。

  • このプロキシー用のクライアント証明書を生成します。この証明書は、x509 証明書ツールを使用して生成できます。信頼されたヘッダーを送信する要求を検証するために、生成した CA でクライアント証明書に署名する必要があります。
  • アイデンティティープロバイダーのカスタムリソース (CR) を作成します。

手順

このプロキシーはクライアント証明書を使用して OAuth サーバーに接続します。これは、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 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
    Copy to Clipboard Toggle word wrap
    注記

    https://<namespace_route> アドレスは OAuth サーバーへのルートであり、oc get route -n openshift-authentication を実行して取得できます。

  3. カスタムリソース (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
    Copy to Clipboard Toggle word wrap

  4. 設定を確認します。

    1. 適切なクライアント証明書およびヘッダーを指定して、トークンを要求し、プロキシーをバイパスできることを確認します。 

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

    2. クライアント証明書を提供しない要求が、証明書なしでトークンを要求して失敗することを確認します。 

      # curl -L -k -H "X-Remote-User: joe" \
   https://<namespace_route>/oauth/token/request
      Copy to Clipboard Toggle word wrap

    3. challengeURL リダイレクトがアクティブであることを確認します。 

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

      以下の手順で使用する challengeURL リダイレクトをコピーします。

    4. このコマンドを実行して、WWW-Authenticate 基本チャレンジ、ネゴシエートチャレンジ、またはそれらの両方のチャレンジを含む 401 応答を表示します。 

      # curl -k -v -H 'X-Csrf-Token: 1' \
   <challengeURL_redirect + query>
      Copy to Clipboard Toggle word wrap

    5. Kerberos チケットを使用または使用せずに、OpenShift CLI (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