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 서버에 연결합니다.
-
Apache 구성에 대한 인증서를 생성합니다.
SSLProxyMachineCertificateFile
매개변수 값으로 지정하는 인증서는 서버에 프록시를 인증하는 데 사용되는 프록시의 클라이언트 인증서입니다. 확장 키 유형으로TLS 웹 클라이언트 인증
을 사용해야 합니다. 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
을 실행하여 가져올 수 있습니다.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
구성을 확인합니다.
올바른 클라이언트 인증서 및 헤더를 제공하는 방식으로 토큰을 요청하여 프록시를 바이패스할 수 있는지 확인합니다.
# curl -L -k -H "X-Remote-User: joe" \ --cert /etc/pki/tls/certs/authproxy.pem \ https://<namespace_route>/oauth/token/request
인증서 없이 토큰을 요청하여 클라이언트 인증서를 제공하지 않는 요청이 실패하는지 확인합니다.
# curl -L -k -H "X-Remote-User: joe" \ https://<namespace_route>/oauth/token/request
challengeURL
리디렉션이 활성화되어 있는지 확인합니다.# curl -k -v -H 'X-Csrf-Token: 1' \ https://<namespace_route>/oauth/authorize?client_id=openshift-challenging-client&response_type=token
다음 단계에서 사용할
challengeURL
리디렉션을 복사합니다.WWW-Authenticate
기본 챌린지, 협상 챌린지 또는 두 가지 챌린지로401
응답을 표시하려면 이 명령을 실행합니다.# curl -k -v -H 'X-Csrf-Token: 1' \ <challengeURL_redirect + query>
Kerberos 티켓을 사용하거나 사용하지 않고 OpenShift CLI(
oc
) 로그인을 테스트합니다.kinit
를 사용하여 Kerberos 티켓을 생성한 경우 이를 삭제합니다.# kdestroy -c cache_name 1
- 1
- Kerberos 캐시의 이름을 제공해야 합니다.
Kerberos 인증 정보를 사용하여
oc
도구에 로그인합니다.# oc login -u <username>
프롬프트에 Kerberos 암호를 입력합니다.
oc
도구에서 로그아웃합니다.# oc logout
Kerberos 인증 정보를 사용하여 티켓을 받습니다.
# kinit
프롬프트에 Kerberos 사용자 이름과 암호를 입력합니다.
oc
도구에 로그인할 수 있는지 확인합니다.# oc login
구성이 올바르면 별도의 인증 정보를 입력하지 않아도 로그인할 수 있습니다.