7.5. 要求ヘッダーアイデンティティープロバイダーの設定

手順

1. 定義された 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この場合は、この警告を無視しても問題ありません。

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

   $ oc login -u <username>

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

   $ oc whoami

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 -u <username>

         プロンプトで、Kerberos パスワードを入力します。

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

         # oc logout

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

         # kinit

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

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

         # oc login

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