InfoGrab Docs

GitLab과 Kerberos 통합

요약

GitLab은 인증 메커니즘으로 Kerberos와 통합할 수 있습니다. Kerberos는 GitLab Enterprise Edition(EE)을 사용하는 인스턴스에서만 사용 가능합니다. GitLab CI/CD는 통합이 전용 포트를 사용하도록 설정되지 않는 한 Kerberos가 활성화된 GitLab 인스턴스에서 작동하지 않습니다.

GitLab은 인증 메커니즘으로 Kerberos와 통합할 수 있습니다.

Kerberos는 GitLab Enterprise Edition(EE)을 사용하는 인스턴스에서만 사용 가능합니다. GitLab Community Edition(CE)을 실행 중인 경우 GitLab CE에서 GitLab EE로 전환할 수 있습니다.

Warning

GitLab CI/CD는 통합이 전용 포트를 사용하도록 설정되지 않는 한 Kerberos가 활성화된 GitLab 인스턴스에서 작동하지 않습니다.

구성#

GitLab이 Kerberos 토큰 기반 인증을 제공하려면 다음 사전 요구사항을 수행하세요. 여전히 영역 지정 등 Kerberos 사용을 위한 시스템을 구성해야 합니다. GitLab은 시스템의 Kerberos 설정을 사용합니다.

GitLab 키탭#

  1. GitLab 서버의 HTTP 서비스에 대한 Kerberos 서비스 프린시팔을 생성합니다. GitLab 서버가 gitlab.example.com이고 Kerberos 영역이 EXAMPLE.COM인 경우, Kerberos 데이터베이스에 서비스 프린시팔 HTTP/gitlab.example.com@EXAMPLE.COM을 생성합니다.
  2. 서비스 프린시팔에 대해 GitLab 서버에 키탭을 생성합니다. 예를 들어 /etc/http.keytab.

키탭은 민감한 파일이므로 GitLab 사용자가 읽을 수 있어야 합니다. 소유권을 설정하고 파일을 적절히 보호합니다:

sudo chown git /etc/http.keytab
sudo chmod 0600 /etc/http.keytab

GitLab 구성#

소스 컴파일 설치#

Note

소스 컴파일 설치의 경우 kerberos gem 그룹이 설치되어 있는지 확인합니다.

  1. Kerberos 티켓 기반 인증을 활성화하기 위해 gitlab.yml의 kerberos 섹션을 편집합니다. 대부분의 경우 Kerberos를 활성화하고 키탭 위치를 지정하기만 하면 됩니다:

    omniauth:
  enabled: true
  allow_single_sign_on: ['kerberos']

kerberos:
  # Git 클라이언트에 대한 HTTP Negotiate 인증 방법 허용
  enabled: true

  # Kerberos 5 키탭 파일. 키탭 파일은 GitLab 사용자가 읽을 수 있어야 하며,
  # 시스템의 다른 키탭과 달라야 합니다.
  # (기본값: Krb5 구성의 기본 키탭 사용)
  keytab: /etc/http.keytab

  2. 변경 사항을 적용하기 위해 GitLab을 재시작합니다.

Linux 패키지 설치#

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    gitlab_rails['omniauth_allow_single_sign_on'] = ['kerberos']

gitlab_rails['kerberos_enabled'] = true
gitlab_rails['kerberos_keytab'] = "/etc/http.keytab"

    Kerberos를 통한 첫 번째 로그인 시 GitLab이 자동으로 사용자를 생성하지 않도록 하려면 gitlab_rails['omniauth_allow_single_sign_on']에 kerberos를 설정하지 마세요.

  2. 변경 사항을 적용하기 위해 GitLab을 재구성합니다.

이제 GitLab은 로그인 및 HTTP Git 액세스에 대한 negotiate 인증 방법을 제공하여, 이 인증 프로토콜을 지원하는 Git 클라이언트가 Kerberos 토큰으로 인증할 수 있습니다.

싱글 사인온 활성화#

공통 설정을 구성하여 kerberos를 싱글 사인온 프로바이더로 추가합니다. 이렇게 하면 기존 GitLab 계정이 없는 사용자를 위한 Just-In-Time 계정 프로비저닝이 활성화됩니다.

Kerberos 계정 생성 및 연결#

Kerberos 계정을 기존 GitLab 계정에 연결하거나, Kerberos 사용자가 로그인을 시도할 때 새 계정을 생성하도록 GitLab을 설정할 수 있습니다.

Kerberos 계정을 기존 GitLab 계정에 연결#

히스토리
  • Kerberos SPNEGO가 GitLab 15.4에서 Kerberos로 이름 변경되었습니다.

관리자라면 기존 GitLab 계정에 Kerberos 계정을 연결할 수 있습니다. 이렇게 하려면:

  1. 오른쪽 상단 모서리에서 관리자를 선택합니다.
  2. 왼쪽 사이드바에서 개요 > 사용자를 선택합니다.
  3. 사용자를 선택한 다음 ID 탭을 선택합니다.
  4. 프로바이더 드롭다운 목록에서 Kerberos를 선택합니다.
  5. 식별자가 Kerberos 사용자 이름에 해당하는지 확인합니다.
  6. 변경 사항 저장을 선택합니다.

관리자가 아닌 경우:

  1. 오른쪽 상단 모서리에서 아바타를 선택합니다.
  2. 프로파일 편집을 선택합니다.
  3. 왼쪽 사이드바에서 액세스 > 비밀번호 및 인증을 선택합니다.
  4. 서비스 로그인 섹션에서 Kerberos 연결을 선택합니다. 서비스 로그인 Kerberos 옵션이 보이지 않으면 싱글 사인온 활성화의 요구사항을 따르세요.

두 경우 모두, 이제 Kerberos 자격 증명으로 GitLab 계정에 로그인할 수 있어야 합니다.

첫 번째 로그인 시 계정 생성#

사용자가 Kerberos 계정으로 처음 GitLab에 로그인하면 GitLab은 일치하는 계정을 생성합니다. 계속하기 전에 Linux 패키지 및 소스 컴파일 인스턴스에 대한 공통 구성 설정 옵션을 검토합니다. kerberos도 포함해야 합니다.

해당 정보를 바탕으로:

  1. allow_single_sign_on 설정에 'kerberos'를 포함합니다.
  2. 지금은 기본 block_auto_created_users 옵션인 true를 수락합니다.
  3. 사용자가 Kerberos 자격 증명으로 로그인을 시도하면 GitLab은 새 계정을 생성합니다.

    1. block_auto_created_users가 true이면 Kerberos 사용자에게 다음과 같은 메시지가 표시될 수 있습니다:

      Your account has been blocked. Please contact your GitLab
administrator if you think this is an error.
      1. 관리자로서 새로운 차단된 계정을 확인할 수 있습니다:
        1. 오른쪽 상단 모서리에서 관리자를 선택합니다.
        2. 왼쪽 사이드바에서 개요 > 사용자를 선택하고 차단됨 탭을 검토합니다.
      2. 사용자를 활성화할 수 있습니다.

    2. block_auto_created_users가 false이면 Kerberos 사용자가 인증되어 GitLab에 로그인됩니다.

Warning

block_auto_created_users의 기본값을 유지하는 것을 권장합니다. 관리자 지식 없이 GitLab에 계정을 생성하는 Kerberos 사용자는 보안 위험이 될 수 있습니다.

Kerberos와 LDAP 계정 함께 연결#

사용자가 Kerberos로 로그인하지만 LDAP 통합도 활성화된 경우, 사용자는 첫 번째 로그인 시 LDAP 계정에 연결됩니다. 이것이 작동하려면 몇 가지 사전 요구사항을 충족해야 합니다:

Kerberos 사용자 이름은 LDAP 사용자의 UID와 일치해야 합니다. GitLab LDAP 구성에서 UID로 사용되는 LDAP 속성을 선택할 수 있지만 Active Directory의 경우 sAMAccountName이어야 합니다.

Kerberos 영역은 LDAP 사용자의 고유 이름(DN)의 도메인 부분과 일치해야 합니다. 예를 들어 Kerberos 영역이 AD.EXAMPLE.COM이면 LDAP 사용자의 고유 이름은 dc=ad,dc=example,dc=com으로 끝나야 합니다.

이러한 규칙을 함께 고려하면 사용자의 Kerberos 사용자 이름이 foo@AD.EXAMPLE.COM 형태이고 LDAP 고유 이름이 sAMAccountName=foo,dc=ad,dc=example,dc=com처럼 보이는 경우에만 연결이 작동합니다.

사용자 지정 허용 영역#

사용자의 Kerberos 영역이 사용자 LDAP DN의 도메인과 일치하지 않을 때 사용자 지정 허용 영역을 구성할 수 있습니다. 구성 값은 사용자가 가질 것으로 예상되는 모든 도메인을 지정해야 합니다. 다른 도메인은 무시되고 LDAP 아이덴티티가 연결되지 않습니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    gitlab_rails['kerberos_simple_ldap_linking_allowed_realms'] = ['example.com','kerberos.example.com']

  2. 파일을 저장하고 변경 사항을 적용하기 위해 GitLab을 재구성합니다.

  1. config/gitlab.yml을 편집합니다:

    kerberos:
  simple_ldap_linking_allowed_realms: ['example.com','kerberos.example.com']

  2. 파일을 저장하고 변경 사항을 적용하기 위해 GitLab을 재시작합니다.

HTTP Git 액세스#

연결된 Kerberos 계정을 통해 Kerberos 계정과 표준 GitLab 자격 증명을 모두 사용하여 git pull 및 git push를 수행할 수 있습니다.

연결된 Kerberos 계정이 있는 GitLab 사용자는 Kerberos 토큰을 사용하여 git pull 및 git push를 수행할 수도 있습니다. 즉, 각 작업마다 비밀번호를 전송할 필요가 없습니다.

Warning

버전 7.64.1 이전의 libcurl에는 협상 시 연결을 재사용하지 않는 알려진 문제가 있습니다. 이로 인해 푸시가 http.postBuffer 구성보다 큰 경우 인증 문제가 발생합니다. 이를 방지하기 위해 Git이 최소 libcurl 7.64.1을 사용하는지 확인합니다. 설치된 libcurl 버전을 확인하려면 curl-config --version을 실행하세요.

Kerberos 토큰을 사용한 HTTP Git 액세스 (비밀번호 없는 인증)#

현재 Git 버전의 버그 때문에 git CLI 명령은 HTTP 서버가 negotiate 인증 방법을 제공하면 이 방법만 사용합니다. 이 방법이 실패하더라도 마찬가지입니다(예: 클라이언트에 Kerberos 토큰이 없는 경우). 따라서 Kerberos 인증이 실패하면 임베디드 사용자 이름 및 비밀번호(basic 인증이라고도 함)로 폴백하는 것이 불가능합니다.

현재 Git 버전을 사용하여 basic 또는 negotiate 인증을 모두 사용할 수 있도록 하려면, 표준 포트가 basic 인증만 제공하는 동안 다른 포트(예: 8443)에서 Kerberos 티켓 기반 인증을 제공하는 것이 가능합니다.

Note

Git 2.4 이상은 사용자 이름과 비밀번호가 대화식으로 또는 자격 증명 관리자를 통해 전달되면 basic 인증으로 폴백을 지원합니다. 사용자 이름과 비밀번호가 URL의 일부로 전달되면 폴백에 실패합니다. 예를 들어 CI/CD 잡 토큰으로 인증하는 GitLab CI/CD 잡에서 이런 일이 발생할 수 있습니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    gitlab_rails['kerberos_use_dedicated_port'] = true
gitlab_rails['kerberos_port'] = 8443
gitlab_rails['kerberos_https'] = true

  2. 변경 사항을 적용하기 위해 GitLab을 재구성합니다.

  1. GitLab의 NGINX 구성 파일(예: /etc/nginx/sites-available/gitlab-ssl)을 편집하고 NGINX가 표준 HTTPS 포트 외에도 포트 8443을 수신하도록 구성합니다:

    server {
  listen 0.0.0.0:443 ssl;
  listen [::]:443 ipv6only=on ssl default_server;
  listen 0.0.0.0:8443 ssl;
  listen [::]:8443 ipv6only=on ssl;

  2. gitlab.yml의 kerberos 섹션을 업데이트합니다:

    kerberos:
  # 전용 포트: Git 2.4 이전은 Negotiate가 실패하면 Basic 인증으로 폴백하지 않습니다.
  # 구형 Git 버전에서 Basic 및 Negotiate 방법을 모두 지원하려면
  # nginx를 구성하여 GitLab을 추가 포트(예: 8443)에서 프록시하고
  # 다음 줄의 주석을 해제하여 이 포트를 Kerberos 인증에 전용합니다. (기본값: false)
  use_dedicated_port: true
  port: 8443
  https: true

  3. 변경 사항을 적용하기 위해 GitLab을 재시작하고 NGINX를 재시작합니다.

이 변경 후, Kerberos 티켓 기반 인증을 사용하려면 Git 원격 URL을 https://gitlab.example.com:8443/mygroup/myproject.git으로 업데이트해야 합니다.

비밀번호 기반에서 티켓 기반 Kerberos 로그인으로 업그레이드#

이전 버전의 GitLab에서는 사용자가 로그인할 때 Kerberos 사용자 이름과 비밀번호를 GitLab에 제출해야 했습니다.

GitLab 15.0에서 비밀번호 기반 Kerberos 로그인을 제거했습니다.

Active Directory Kerberos 환경 지원#

Active Directory 도메인에서 Kerberos 티켓 기반 인증을 사용할 때, Kerberos 프로토콜의 확장으로 인해 HTTP 인증 헤더가 기본 크기인 8 kB보다 커질 수 있으므로 NGINX에서 허용하는 최대 헤더 크기를 늘려야 할 수 있습니다. NGINX 구성에서 large_client_header_buffers를 더 큰 값으로 구성합니다.

Windows AD에서 AES 전용 암호화로 생성된 키탭 사용#

AES(고급 암호화 표준) 전용 암호화로 키탭을 생성할 때, AD 서버에서 해당 계정의 이 계정은 Kerberos AES <128/256> 비트 암호화를 지원합니다 체크박스를 선택해야 합니다. 체크박스가 128 비트인지 256 비트인지는 키탭을 생성할 때 사용한 암호화 강도에 따라 다릅니다. Active Directory 서버에서 확인하려면:

  1. 사용자 및 그룹 도구를 엽니다.
  2. 키탭을 생성하는 데 사용한 계정을 찾습니다.
  3. 계정을 마우스 오른쪽 버튼으로 클릭하고 속성을 선택합니다.
  4. 계정 탭의 계정 옵션에서 적절한 AES 암호화 지원 체크박스를 선택합니다.
  5. 저장하고 닫습니다.

GitLab과 Kerberos 통합

Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기
요약

GitLab은 인증 메커니즘으로 Kerberos와 통합할 수 있습니다. Kerberos는 GitLab Enterprise Edition(EE)을 사용하는 인스턴스에서만 사용 가능합니다. GitLab CI/CD는 통합이 전용 포트를 사용하도록 설정되지 않는 한 Kerberos가 활성화된 GitLab 인스턴스에서 작동하지 않습니다.

GitLab은 인증 메커니즘으로 Kerberos와 통합할 수 있습니다.

Kerberos는 GitLab Enterprise Edition(EE)을 사용하는 인스턴스에서만 사용 가능합니다. GitLab Community Edition(CE)을 실행 중인 경우 GitLab CE에서 GitLab EE로 전환할 수 있습니다.

Warning

GitLab CI/CD는 통합이 전용 포트를 사용하도록 설정되지 않는 한 Kerberos가 활성화된 GitLab 인스턴스에서 작동하지 않습니다.

구성#

GitLab이 Kerberos 토큰 기반 인증을 제공하려면 다음 사전 요구사항을 수행하세요. 여전히 영역 지정 등 Kerberos 사용을 위한 시스템을 구성해야 합니다. GitLab은 시스템의 Kerberos 설정을 사용합니다.

GitLab 키탭#

  1. GitLab 서버의 HTTP 서비스에 대한 Kerberos 서비스 프린시팔을 생성합니다. GitLab 서버가 gitlab.example.com이고 Kerberos 영역이 EXAMPLE.COM인 경우, Kerberos 데이터베이스에 서비스 프린시팔 HTTP/gitlab.example.com@EXAMPLE.COM을 생성합니다.
  2. 서비스 프린시팔에 대해 GitLab 서버에 키탭을 생성합니다. 예를 들어 /etc/http.keytab.

키탭은 민감한 파일이므로 GitLab 사용자가 읽을 수 있어야 합니다. 소유권을 설정하고 파일을 적절히 보호합니다:

sudo chown git /etc/http.keytab
sudo chmod 0600 /etc/http.keytab

GitLab 구성#

소스 컴파일 설치#

Note

소스 컴파일 설치의 경우 kerberos gem 그룹이 설치되어 있는지 확인합니다.

  1. Kerberos 티켓 기반 인증을 활성화하기 위해 gitlab.yml의 kerberos 섹션을 편집합니다. 대부분의 경우 Kerberos를 활성화하고 키탭 위치를 지정하기만 하면 됩니다:

    omniauth:
  enabled: true
  allow_single_sign_on: ['kerberos']

kerberos:
  # Git 클라이언트에 대한 HTTP Negotiate 인증 방법 허용
  enabled: true

  # Kerberos 5 키탭 파일. 키탭 파일은 GitLab 사용자가 읽을 수 있어야 하며,
  # 시스템의 다른 키탭과 달라야 합니다.
  # (기본값: Krb5 구성의 기본 키탭 사용)
  keytab: /etc/http.keytab

  2. 변경 사항을 적용하기 위해 GitLab을 재시작합니다.

Linux 패키지 설치#

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    gitlab_rails['omniauth_allow_single_sign_on'] = ['kerberos']

gitlab_rails['kerberos_enabled'] = true
gitlab_rails['kerberos_keytab'] = "/etc/http.keytab"

    Kerberos를 통한 첫 번째 로그인 시 GitLab이 자동으로 사용자를 생성하지 않도록 하려면 gitlab_rails['omniauth_allow_single_sign_on']에 kerberos를 설정하지 마세요.

  2. 변경 사항을 적용하기 위해 GitLab을 재구성합니다.

이제 GitLab은 로그인 및 HTTP Git 액세스에 대한 negotiate 인증 방법을 제공하여, 이 인증 프로토콜을 지원하는 Git 클라이언트가 Kerberos 토큰으로 인증할 수 있습니다.

싱글 사인온 활성화#

공통 설정을 구성하여 kerberos를 싱글 사인온 프로바이더로 추가합니다. 이렇게 하면 기존 GitLab 계정이 없는 사용자를 위한 Just-In-Time 계정 프로비저닝이 활성화됩니다.

Kerberos 계정 생성 및 연결#

Kerberos 계정을 기존 GitLab 계정에 연결하거나, Kerberos 사용자가 로그인을 시도할 때 새 계정을 생성하도록 GitLab을 설정할 수 있습니다.

Kerberos 계정을 기존 GitLab 계정에 연결#

히스토리
  • Kerberos SPNEGO가 GitLab 15.4에서 Kerberos로 이름 변경되었습니다.

관리자라면 기존 GitLab 계정에 Kerberos 계정을 연결할 수 있습니다. 이렇게 하려면:

  1. 오른쪽 상단 모서리에서 관리자를 선택합니다.
  2. 왼쪽 사이드바에서 개요 > 사용자를 선택합니다.
  3. 사용자를 선택한 다음 ID 탭을 선택합니다.
  4. 프로바이더 드롭다운 목록에서 Kerberos를 선택합니다.
  5. 식별자가 Kerberos 사용자 이름에 해당하는지 확인합니다.
  6. 변경 사항 저장을 선택합니다.

관리자가 아닌 경우:

  1. 오른쪽 상단 모서리에서 아바타를 선택합니다.
  2. 프로파일 편집을 선택합니다.
  3. 왼쪽 사이드바에서 액세스 > 비밀번호 및 인증을 선택합니다.
  4. 서비스 로그인 섹션에서 Kerberos 연결을 선택합니다. 서비스 로그인 Kerberos 옵션이 보이지 않으면 싱글 사인온 활성화의 요구사항을 따르세요.

두 경우 모두, 이제 Kerberos 자격 증명으로 GitLab 계정에 로그인할 수 있어야 합니다.

첫 번째 로그인 시 계정 생성#

사용자가 Kerberos 계정으로 처음 GitLab에 로그인하면 GitLab은 일치하는 계정을 생성합니다. 계속하기 전에 Linux 패키지 및 소스 컴파일 인스턴스에 대한 공통 구성 설정 옵션을 검토합니다. kerberos도 포함해야 합니다.

해당 정보를 바탕으로:

  1. allow_single_sign_on 설정에 'kerberos'를 포함합니다.
  2. 지금은 기본 block_auto_created_users 옵션인 true를 수락합니다.
  3. 사용자가 Kerberos 자격 증명으로 로그인을 시도하면 GitLab은 새 계정을 생성합니다.

    1. block_auto_created_users가 true이면 Kerberos 사용자에게 다음과 같은 메시지가 표시될 수 있습니다:

      Your account has been blocked. Please contact your GitLab
administrator if you think this is an error.
      1. 관리자로서 새로운 차단된 계정을 확인할 수 있습니다:
        1. 오른쪽 상단 모서리에서 관리자를 선택합니다.
        2. 왼쪽 사이드바에서 개요 > 사용자를 선택하고 차단됨 탭을 검토합니다.
      2. 사용자를 활성화할 수 있습니다.

    2. block_auto_created_users가 false이면 Kerberos 사용자가 인증되어 GitLab에 로그인됩니다.

Warning

block_auto_created_users의 기본값을 유지하는 것을 권장합니다. 관리자 지식 없이 GitLab에 계정을 생성하는 Kerberos 사용자는 보안 위험이 될 수 있습니다.

Kerberos와 LDAP 계정 함께 연결#

사용자가 Kerberos로 로그인하지만 LDAP 통합도 활성화된 경우, 사용자는 첫 번째 로그인 시 LDAP 계정에 연결됩니다. 이것이 작동하려면 몇 가지 사전 요구사항을 충족해야 합니다:

Kerberos 사용자 이름은 LDAP 사용자의 UID와 일치해야 합니다. GitLab LDAP 구성에서 UID로 사용되는 LDAP 속성을 선택할 수 있지만 Active Directory의 경우 sAMAccountName이어야 합니다.

Kerberos 영역은 LDAP 사용자의 고유 이름(DN)의 도메인 부분과 일치해야 합니다. 예를 들어 Kerberos 영역이 AD.EXAMPLE.COM이면 LDAP 사용자의 고유 이름은 dc=ad,dc=example,dc=com으로 끝나야 합니다.

이러한 규칙을 함께 고려하면 사용자의 Kerberos 사용자 이름이 foo@AD.EXAMPLE.COM 형태이고 LDAP 고유 이름이 sAMAccountName=foo,dc=ad,dc=example,dc=com처럼 보이는 경우에만 연결이 작동합니다.

사용자 지정 허용 영역#

사용자의 Kerberos 영역이 사용자 LDAP DN의 도메인과 일치하지 않을 때 사용자 지정 허용 영역을 구성할 수 있습니다. 구성 값은 사용자가 가질 것으로 예상되는 모든 도메인을 지정해야 합니다. 다른 도메인은 무시되고 LDAP 아이덴티티가 연결되지 않습니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    gitlab_rails['kerberos_simple_ldap_linking_allowed_realms'] = ['example.com','kerberos.example.com']

  2. 파일을 저장하고 변경 사항을 적용하기 위해 GitLab을 재구성합니다.

  1. config/gitlab.yml을 편집합니다:

    kerberos:
  simple_ldap_linking_allowed_realms: ['example.com','kerberos.example.com']

  2. 파일을 저장하고 변경 사항을 적용하기 위해 GitLab을 재시작합니다.

HTTP Git 액세스#

연결된 Kerberos 계정을 통해 Kerberos 계정과 표준 GitLab 자격 증명을 모두 사용하여 git pull 및 git push를 수행할 수 있습니다.

연결된 Kerberos 계정이 있는 GitLab 사용자는 Kerberos 토큰을 사용하여 git pull 및 git push를 수행할 수도 있습니다. 즉, 각 작업마다 비밀번호를 전송할 필요가 없습니다.

Warning

버전 7.64.1 이전의 libcurl에는 협상 시 연결을 재사용하지 않는 알려진 문제가 있습니다. 이로 인해 푸시가 http.postBuffer 구성보다 큰 경우 인증 문제가 발생합니다. 이를 방지하기 위해 Git이 최소 libcurl 7.64.1을 사용하는지 확인합니다. 설치된 libcurl 버전을 확인하려면 curl-config --version을 실행하세요.

Kerberos 토큰을 사용한 HTTP Git 액세스 (비밀번호 없는 인증)#

현재 Git 버전의 버그 때문에 git CLI 명령은 HTTP 서버가 negotiate 인증 방법을 제공하면 이 방법만 사용합니다. 이 방법이 실패하더라도 마찬가지입니다(예: 클라이언트에 Kerberos 토큰이 없는 경우). 따라서 Kerberos 인증이 실패하면 임베디드 사용자 이름 및 비밀번호(basic 인증이라고도 함)로 폴백하는 것이 불가능합니다.

현재 Git 버전을 사용하여 basic 또는 negotiate 인증을 모두 사용할 수 있도록 하려면, 표준 포트가 basic 인증만 제공하는 동안 다른 포트(예: 8443)에서 Kerberos 티켓 기반 인증을 제공하는 것이 가능합니다.

Note

Git 2.4 이상은 사용자 이름과 비밀번호가 대화식으로 또는 자격 증명 관리자를 통해 전달되면 basic 인증으로 폴백을 지원합니다. 사용자 이름과 비밀번호가 URL의 일부로 전달되면 폴백에 실패합니다. 예를 들어 CI/CD 잡 토큰으로 인증하는 GitLab CI/CD 잡에서 이런 일이 발생할 수 있습니다.

  1. /etc/gitlab/gitlab.rb를 편집합니다:

    gitlab_rails['kerberos_use_dedicated_port'] = true
gitlab_rails['kerberos_port'] = 8443
gitlab_rails['kerberos_https'] = true

  2. 변경 사항을 적용하기 위해 GitLab을 재구성합니다.

  1. GitLab의 NGINX 구성 파일(예: /etc/nginx/sites-available/gitlab-ssl)을 편집하고 NGINX가 표준 HTTPS 포트 외에도 포트 8443을 수신하도록 구성합니다:

    server {
  listen 0.0.0.0:443 ssl;
  listen [::]:443 ipv6only=on ssl default_server;
  listen 0.0.0.0:8443 ssl;
  listen [::]:8443 ipv6only=on ssl;

  2. gitlab.yml의 kerberos 섹션을 업데이트합니다:

    kerberos:
  # 전용 포트: Git 2.4 이전은 Negotiate가 실패하면 Basic 인증으로 폴백하지 않습니다.
  # 구형 Git 버전에서 Basic 및 Negotiate 방법을 모두 지원하려면
  # nginx를 구성하여 GitLab을 추가 포트(예: 8443)에서 프록시하고
  # 다음 줄의 주석을 해제하여 이 포트를 Kerberos 인증에 전용합니다. (기본값: false)
  use_dedicated_port: true
  port: 8443
  https: true

  3. 변경 사항을 적용하기 위해 GitLab을 재시작하고 NGINX를 재시작합니다.

이 변경 후, Kerberos 티켓 기반 인증을 사용하려면 Git 원격 URL을 https://gitlab.example.com:8443/mygroup/myproject.git으로 업데이트해야 합니다.

비밀번호 기반에서 티켓 기반 Kerberos 로그인으로 업그레이드#

이전 버전의 GitLab에서는 사용자가 로그인할 때 Kerberos 사용자 이름과 비밀번호를 GitLab에 제출해야 했습니다.

GitLab 15.0에서 비밀번호 기반 Kerberos 로그인을 제거했습니다.

Active Directory Kerberos 환경 지원#

Active Directory 도메인에서 Kerberos 티켓 기반 인증을 사용할 때, Kerberos 프로토콜의 확장으로 인해 HTTP 인증 헤더가 기본 크기인 8 kB보다 커질 수 있으므로 NGINX에서 허용하는 최대 헤더 크기를 늘려야 할 수 있습니다. NGINX 구성에서 large_client_header_buffers를 더 큰 값으로 구성합니다.

Windows AD에서 AES 전용 암호화로 생성된 키탭 사용#

AES(고급 암호화 표준) 전용 암호화로 키탭을 생성할 때, AD 서버에서 해당 계정의 이 계정은 Kerberos AES <128/256> 비트 암호화를 지원합니다 체크박스를 선택해야 합니다. 체크박스가 128 비트인지 256 비트인지는 키탭을 생성할 때 사용한 암호화 강도에 따라 다릅니다. Active Directory 서버에서 확인하려면:

  1. 사용자 및 그룹 도구를 엽니다.
  2. 키탭을 생성하는 데 사용한 계정을 찾습니다.
  3. 계정을 마우스 오른쪽 버튼으로 클릭하고 속성을 선택합니다.
  4. 계정 탭의 계정 옵션에서 적절한 AES 암호화 지원 체크박스를 선택합니다.
  5. 저장하고 닫습니다.