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

    CA는 ConfigMap 오브젝트의 ca.crt 키에 저장해야 합니다.

  • 프록시의 클라이언트 인증서를 생성합니다. 이 인증서는 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

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

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.