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

    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
    注記

    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
  4. 設定を確認します。

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

      # curl -L -k -H "X-Remote-User: joe" \
         --cert /etc/pki/tls/certs/authproxy.pem \
         https://<namespace_route>/oauth/token/request
    2. クライアント証明書を提供しない要求が、証明書なしでトークンを要求して失敗することを確認します。

      # curl -L -k -H "X-Remote-User: joe" \
         https://<namespace_route>/oauth/token/request
    3. challengeURL リダイレクトがアクティブであることを確認します。

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

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

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

      # curl -k -v -H 'X-Csrf-Token: 1' \
         <challengeURL_redirect + query>
    5. Kerberos チケットを使用または使用せずに、OpenShift CLI (oc) へのログインをテストします。

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

        # kdestroy -c cache_name 1
        1
        Kerberos キャッシュの名前を指定します。
      2. Kerberos 認証情報を使用して oc ツールにログインします。

        # oc login

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

      3. oc ツールからログアウトします。

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

        # kinit

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

      5. oc ツールにログインできることを確認します。

        # oc login

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

Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

© 2024 Red Hat, Inc.