7.5.6. 요청 헤더를 사용하는 Apache 인증 구성 예

이 예제에서는 요청 헤더 ID 공급자를 사용하여 OpenShift Container Platform에 대한 Apache 인증 프록시를 구성합니다.

사용자 정의 프록시 구성

mod_auth_gssapi 모듈을 사용하는 것은 요청 헤더 ID 공급자를 사용하여 Apache 인증 프록시를 구성하는 일반적인 방법입니다. 그러나 필수는 아닙니다. 다음 요구 사항이 충족되면 다른 프록시를 쉽게 사용할 수 있습니다.

  • 스푸핑을 방지하기 위해 클라이언트 요청에서 X-Remote-User 헤더를 차단합니다.
  • RequestHeaderIdentityProvider 구성에서 클라이언트 인증서 인증을 시행합니다.
  • 챌린지 flow를 사용하는 모든 인증 요청에 대해 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 모듈을 사용하여 요청 헤더 ID 공급자를 통한 Apache 인증 프록시를 구성합니다.

사전 요구 사항

  • 선택적 채널에서 mod_auth_gssapi 모듈을 가져옵니다. 로컬 시스템에 다음 패키지가 설치되어 있어야 합니다.

    • 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 1
    1
    CA는 ConfigMap 오브젝트의 ca.crt 키에 저장해야 합니다.
    작은 정보

    다음 YAML을 적용하여 구성 맵을 만들 수 있습니다. 

    apiVersion: v1
kind: ConfigMap
metadata:
  name: ca-config-map
  namespace: openshift-config
type: Opaque
data:
  ca.crt: |
    <CA_certificate_PEM>
  • 프록시의 클라이언트 인증서를 생성합니다. 이 인증서는 x509 인증서 툴링을 사용하여 생성할 수 있습니다. 클라이언트 인증서는 신뢰할 수 있는 헤더를 제출하는 요청을 검증하기 위해 생성한 CA에서 서명해야 합니다.
  • ID 공급자의 CR(사용자 정의 리소스)을 만듭니다.

절차

이 프록시는 클라이언트 인증서를 사용하여 X-Remote-User 헤더를 신뢰하도록 구성된 OAuth 서버에 연결합니다.

  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

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