7.5. 요청 헤더 ID 공급자 구성

절차

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. 암호를 입력하라는 메시지가 표시되면 암호를 입력하여 ID 공급자의 사용자로 클러스터에 로그인합니다.

   $ oc login -u <username>

3. 사용자가 로그인했는지 확인하고 사용자 이름을 표시합니다.

   $ oc whoami

1. Apache 구성에 대한 인증서를 생성합니다. SSLProxyMachineCertificateFile 매개변수 값으로 지정하는 인증서는 서버에 프록시를 인증하는 데 사용되는 프록시의 클라이언트 인증서입니다. 확장 키 유형으로 TLS 웹 클라이언트 인증을 사용해야 합니다.

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

         구성이 올바르면 별도의 인증 정보를 입력하지 않아도 로그인할 수 있습니다.