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

X-Remote - User 와 같은 요청 헤더 값에서 사용자를 식별하도록 요청 헤더 ID 공급자를 구성합니다. 일반적으로 요청 헤더 값을 설정하는 인증 프록시와 함께 사용됩니다.

7.5.1. OpenShift Container Platform의 ID 공급자 정보

기본적으로는 kubeadmin 사용자만 클러스터에 있습니다. ID 공급자를 지정하려면 해당 ID 공급자를 설명하는 CR(사용자 정의 리소스)을 생성하여 클러스터에 추가해야 합니다.

참고

/, :, %를 포함하는 OpenShift Container Platform 사용자 이름은 지원되지 않습니다.

7.5.2. 요청 헤더 인증 정보

요청 헤더 ID 공급자는 X-Remote-User와 같은 요청 헤더 값에서 사용자를 확인합니다. 일반적으로 요청 헤더 값을 설정하는 인증 프록시와 함께 사용됩니다. 요청 헤더 ID 공급자는 htpasswd, Keystone, LDAP 또는 기본 인증과 같이 직접 암호 로그인을 사용하는 다른 ID 공급자와 결합할 수 없습니다.

참고

커뮤니티 지원 SAML 인증과 같은 고급 구성에도 요청 헤더 ID 공급자를 사용할 수 있습니다. 이 솔루션은 Red Hat에서 지원하지 않습니다.

사용자가 이 ID 공급자를 사용하여 인증하려면 인증 프록시를 통해 https://<namespace_route>/oauth/authorize(및 하위 경로)에 액세스해야 합니다. 이를 위해서는 https://<namespace_route>/oauth/authorize로 프록시하는 프록시 끝점으로 OAuth 토큰에 대한 인증되지 않은 요청을 리디렉션하도록 OAuth 서버를 구성해야 합니다.

브라우저 기반 로그인 flows가 필요한 클라이언트의 인증되지 않은 요청을 리디렉션하려면 다음을 수행합니다.

  • provider.loginURL 매개변수를 대화형 클라이언트를 인증하는 인증 프록시 URL로 설정한 다음 요청을 https://<namespace_route>/oauth/authorize로 프록시합니다.

WWW 인증 챌린지가 예상되는 클라이언트의 인증되지 않은 요청을 리디렉션하려면 다음을 수행합니다.

  • provider.challengeURL 매개변수를 WWW 인증 챌린지가 예상되는 클라이언트를 인증하는 인증 프록시 URL로 설정한 후 요청을 https://<namespace_route>/oauth/authorize로 프록시합니다.

provider.challengeURLprovider.loginURL 매개변수는 URL 조회 부분에 다음 토큰을 포함할 수 있습니다.

  • ${url}은 현재 URL로 교체되며 쿼리 매개변수에서 안전하도록 이스케이프됩니다.

    예: https://www.example.com/sso-login?then=${url}

  • ${query}는 이스케이프 처리되지 않은 현재 쿼리 문자열로 교체됩니다.

    예: https://www.example.com/auth-proxy/oauth/authorize?${query}

중요

OpenShift Container Platform 4.1부터는 프록시에서 상호 TLS를 지원해야 합니다.

7.5.2.1. Microsoft Windows에서 SSPI 연결 지원

중요

Microsoft Windows에서 SSPI 연결 지원을 사용하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

OpenShift CLI oc는 Microsft Windows에서 SSO 흐름을 허용하기 위해 SSPI(Security Support Provider Interface)를 지원합니다. 요청 헤더 ID 공급자를 GSSAPI 지원 프록시와 함께 사용하여 Active Directory 서버를 OpenShift Container Platform에 연결하는 경우, 사용자가 도메인에 가입된 Microsoft Windows 컴퓨터에서 oc 명령줄 인터페이스를 사용하여 OpenShift Container Platform을 자동으로 인증할 수 있습니다.

7.5.3. 구성 맵 생성

ID 공급자는 openshift-config 네임스페이스에서 OpenShift Container Platform ConfigMap 오브젝트를 사용하여 인증 기관 번들을 포함합니다. 이들은 주로 ID 공급자에 필요한 인증서 번들을 포함하는 데 사용됩니다.

절차

  • 다음 명령을 사용하여 인증 기관을 포함하는 OpenShift Container Platform ConfigMap 오브젝트를 정의합니다. 인증 기관은ConfigMap 오브젝트의 ca.crt 키에 저장해야 합니다.

    $ oc create configmap ca-config-map --from-file=ca.crt=/path/to/ca -n openshift-config
    작은 정보

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

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: ca-config-map
      namespace: openshift-config
    data:
      ca.crt: |
        <CA_certificate_PEM>

7.5.4. 요청 헤더 CR 샘플

다음 CR(사용자 정의 리소스)에는 요청 헤더 ID 공급자에 대한 매개변수 및 허용 가능한 값이 표시되어 있습니다.

요청 헤더 CR

apiVersion: config.openshift.io/v1
kind: OAuth
metadata:
  name: cluster
spec:
  identityProviders:
  - name: requestheaderidp 1
    mappingMethod: claim 2
    type: RequestHeader
    requestHeader:
      challengeURL: "https://www.example.com/challenging-proxy/oauth/authorize?${query}" 3
      loginURL: "https://www.example.com/login-proxy/oauth/authorize?${query}" 4
      ca: 5
        name: ca-config-map
      clientCommonNames: 6
      - my-auth-proxy
      headers: 7
      - X-Remote-User
      - SSO-User
      emailHeaders: 8
      - X-Remote-User-Email
      nameHeaders: 9
      - X-Remote-User-Display-Name
      preferredUsernameHeaders: 10
      - X-Remote-User-Login

1
이 공급자 이름은 요청 헤더에서 사용자 이름 앞에 접두어로 지정되어 ID 이름을 형성합니다.
2
이 공급자의 ID와 User 오브젝트 간 매핑 설정 방법을 제어합니다.
3
선택 사항: 인증되지 않은 /oauth/authorize 요청을 리디렉션할 URL로, 브라우저 기반 클라이언트를 인증한 다음 해당 요청을 https://<namespace_route>/oauth/authorize로 프록시합니다. OAuth 승인 flows가 제대로 작동하려면 https://<namespace_route>/oauth/authorize로 프록시되는 URL이 /authorize(후행 슬래시 없음)로 끝나야 하며 프록시 하위 경로도 마찬가지입니다. ${url}은 현재 URL로 교체되며 쿼리 매개변수에서 안전하도록 이스케이프됩니다. ${query}는 현재 쿼리 문자열로 교체됩니다. 이 속성이 정의되어 있지 않으면 loginURL을 사용해야 합니다.
4
선택 사항: 인증되지 않은 /oauth/authorize 요청을 리디렉션하는 URL로, WWW-Authenticate 요청을 예상하는 클라이언트를 인증한 다음 https://<namespace_route>/oauth/authorize로 프록시합니다. ${url}은 현재 URL로 교체되며 쿼리 매개변수에서 안전하도록 이스케이프됩니다. ${query}는 현재 쿼리 문자열로 교체됩니다. 이 속성이 정의되지 않은 경우 challengeURL을 사용해야 합니다.
5
PEM 인코딩 인증서 번들이 포함된 OpenShift Container Platform ConfigMap 오브젝트에 대한 참조입니다. 원격 서버에서 제공하는 TLS 인증서의 유효성을 확인하는 신뢰 앵커로 사용됩니다.
중요

OpenShift Container Platform 4.1부터는 이 ID 공급자에 ca 필드가 있어야 합니다. 이는 프록시에서 상호 TLS를 지원해야 함을 의미합니다.

6
선택 사항: 공통 이름(cn) 목록. 설정된 경우 요청 헤더에서 사용자 이름을 확인하기 전에 지정된 목록에 공통 이름(cn)이 있는 유효한 클라이언트 인증서를 제공해야 합니다. 비어 있는 경우 모든 공통 이름이 허용됩니다. ca와 함께만 사용할 수 있습니다.
7
사용자 ID에 대해 순서대로 확인할 헤더 이름입니다. 값을 포함하는 첫 번째 헤더가 ID로 사용됩니다. 필수 항목이며 대소문자를 구분하지 않습니다.
8
이메일 주소를 순서대로 확인할 헤더 이름입니다. 값을 포함하는 첫 번째 헤더가 이메일 주소로 사용됩니다. 선택 항목이며 대소문자를 구분하지 않습니다.
9
표시 이름을 순서대로 확인할 헤더 이름입니다. 값을 포함하는 첫 번째 헤더가 표시 이름으로 사용됩니다. 선택 항목이며 대소문자를 구분하지 않습니다.
10
headers에 지정된 헤더에서 결정된 불변 ID와 다른 경우, 기본 사용자 이름을 순서대로 확인하는 헤더 이름입니다. 값이 포 된 첫 번째 헤더는 프로비저닝시 기본 사용자 이름으로 사용됩니다. 선택 항목이며 대소문자를 구분하지 않습니다.

추가 리소스

7.5.5. 클러스터에 ID 공급자 추가

클러스터를 설치한 후에는 사용자가 인증할 수 있도록 ID 공급자를 추가하십시오.

사전 요구 사항

  • OpenShift Container Platform 클러스터를 생성합니다.
  • ID 공급자의 CR(사용자 정의 리소스)을 만듭니다.
  • 관리자로 로그인해야 합니다.

절차

  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

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

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