GitLab 문제 해결: Kerberos 통합

Tier: Free, Premium, Ultimate Offering: Self-managed

GitLab과 Kerberos 통합으로 작업할 때 다음과 같은 문제가 발생할 수 있습니다.

Windows AD에 대한 Kerberos 인증으로 Google Chrome 사용

Google Chrome을 사용하여 Kerberos로 GitLab에 로그인하려면 전체 사용자 이름을 입력해야 합니다. 예: username@domain.com.

전체 사용자 이름을 입력하지 않으면 로그인에 실패합니다. 로그인 실패의 증거로 다음 이벤트 메시지를 로그에서 확인하세요:

"message":"OmniauthKerberosController: failed to process Negotiate/Kerberos authentication: gss_accept_sec_context did not return GSS_S_COMPLETE: An unsupported mechanism was requested\nUnknown error".

GitLab과 Kerberos 서버 간의 연결 테스트

kinit 및 klist와 같은 유틸리티를 사용하여 GitLab 서버와 Kerberos 서버 간의 연결을 테스트할 수 있습니다. 이를 설치하는 방법은 특정 운영 체제에 따라 다릅니다.

klist를 사용하여 keytab 파일에서 사용 가능한 서비스 주체 이름(SPN) 및 각 SPN의 암호화 유형을 확인하세요:

klist -ke /etc/http.keytab

Ubuntu 서버에서 출력은 다음과 비슷하게 나타납니다:

Keytab name: FILE:/etc/http.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   3 HTTP/my.gitlab.domain@MY.REALM (des-cbc-crc)
   3 HTTP/my.gitlab.domain@MY.REALM (des-cbc-md5)
   3 HTTP/my.gitlab.domain@MY.REALM (arcfour-hmac)
   3 HTTP/my.gitlab.domain@MY.REALM (aes256-cts-hmac-sha1-96)
   3 HTTP/my.gitlab.domain@MY.REALM (aes128-cts-hmac-sha1-96)

kinit를 상세 모드로 사용하여 GitLab이 keytab 파일을 사용하여 Kerberos 서버에 연결할 수 있는지 테스트하세요:

KRB5_TRACE=/dev/stdout kinit -kt /etc/http.keytab HTTP/my.gitlab.domain@MY.REALM

이 명령은 인증 프로세스의 상세한 출력을 보여줍니다.

지원되지 않는 GSSAPI 메커니즘

Kerberos SPNEGO 인증을 사용하면 브라우저가 GitLab에 지원하는 메커니즘 목록을 전송해야 합니다. GitLab이 지원하는 메커니즘을 지원하지 않으면 인증이 실패하고 로그에 다음과 같은 메시지가 기록됩니다:

OmniauthKerberosController: failed to process Negotiate/Kerberos authentication: gss_accept_sec_context did not return GSS_S_COMPLETE: An unsupported mechanism was requested Unknown error

이 오류 메시지에는 여러 가능한 원인과 해결책이 있습니다.

전용 포트를 사용하지 않는 Kerberos 통합

Kerberos 통합이 전용 포트를 사용하도록 구성되지 않으면 GitLab CI/CD는 Kerberos 기능이 활성화된 GitLab 인스턴스와 작동하지 않습니다.

클라이언트 머신과 Kerberos 서버 간의 연결 부족

이는 브라우저가 Kerberos 서버에 직접 연락할 수 없을 때 일반적으로 발생합니다. 이는 GitLab 서버를 Kerberos 서버에 대한 중개자로 사용하려는 지원되지 않는 메커니즘인 IAKERB로 대체됩니다.

이 오류가 발생하는 경우 클라이언트 머신과 Kerberos 서버 간의 연결이 있는지 확인하세요. 이는 필수 조건입니다! 트래픽이 방화벽에 의해 차단되었거나 DNS 레코드가 올바르지 않을 수 있습니다.

GitLab DNS 레코드는 CNAME 레코드입니다 오류

Kerberos는 GitLab이 CNAME 레코드로 참조될 때 이 오류로 실패합니다.

이 문제를 해결하려면 GitLab의 DNS 레코드가 A 레코드인지 확인하세요.

GitLab 인스턴스 호스트 이름의 정방향 및 역방향 DNS 레코드 불일치

다른 실패 모드는 GitLab 서버에 대한 정방향 및 역방향 DNS 레코드가 일치하지 않을 때 발생합니다.

종종, 이 경우 Windows 클라이언트는 작동하지만 Linux 클라이언트는 실패합니다.

이들은 Kerberos 영역을 감지할 때 역방향 DNS를 사용합니다.

잘못된 영역을 감지하면 일반적인 Kerberos 메커니즘이 실패하므로 클라이언트는 IAKERB 협상을 시도하게 되며, 이로 인해 위의 오류 메시지가 발생합니다.

이 문제를 해결하려면 GitLab 서버의 정방향 및 역방향 DNS가 일치하는지 확인하세요.

예를 들어, gitlab.example.com으로 GitLab에 접근하고 IP 주소 10.0.2.2로 해결되면, 2.2.0.10.in-addr.arpa는 gitlab.example.com에 대한 PTR 레코드여야 합니다.

브라우저 또는 클라이언트 머신에서 Kerberos 라이브러리 누락

마지막으로, 브라우저 또는 클라이언트 머신에 Kerberos 지원이 전혀 없을 수도 있습니다.

Kerberos 라이브러리가 설치되어 있고, 다른 Kerberos 서비스에 인증할 수 있는지 확인하세요.

HTTP Basic: 클론할 때 액세스 거부 

remote: HTTP Basic: Access denied
fatal: Authentication failed for '<KRB5 path>'

Git v2.11 이상을 사용 중이고 클론 시 위 오류가 발생한다면, 이 문제를 해결하기 위해 http.emptyAuth Git 옵션을 true로 설정할 수 있습니다:

git config --global http.emptyAuth true

프록시 HTTPS를 통한 Kerberos 클론

다음 사항이 있는 경우 주석 처리해야 합니다:

  • KRB5 Git Cloning으로 클론 옵션에서 https:// URL이 예상될 때 http:// URL이 표시됩니다.
  • HTTPS가 GitLab 인스턴스에서 종료되지 않고, 대신 로드 밸런서 또는 로컬 트래픽 관리자에 의해 프록시됩니다.
# gitlab_rails['kerberos_https'] = false

참고: Git v2.11 릴리즈 노트

유용한 링크