GitLab과 Kerberos 통합

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

GitLab은 인증 매커니즘으로서 Kerberos를 통합할 수 있습니다.

  • GitLab을 구성하여 사용자가 Kerberos 자격 증명으로 로그인할 수 있도록 할 수 있습니다.
  • Kerberos를 사용하여 전송된 암호를 가로채거나 도청하는 것을 방지할 수 있습니다.

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

경고: Kerberos를 사용하는 GitLab 인스턴스에서 GitLab CI/CD가 작동하지 않습니다. 인티그레이션이 전용 포트를 사용하도록 설정되지 않는 한.

구성

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

직접 컴파일된 설치

참고: 직접 컴파일된 설치의 경우, kerberos gem 그룹이 설치되었는지 확인하세요.

  1. gitlab.yml의 kerberos 섹션을 편집하여 Kerberos 티켓 기반 인증을 활성화하세요. 대부분의 경우, Kerberos를 활성화하고 키탭의 위치를 지정하는 것만으로 충분합니다. 

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

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

  # Kerberos 5 keytab 파일. 키탭 파일은 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은 Kerberos 토큰으로 로그인 및 HTTP Git 액세스를 위한 negotiate 인증 방법을 제공하여 해당 인증 프로토콜을 지원하는 Git 클라이언트에서 Kerberos 토큰으로 인증할 수 있도록 합니다.

단일 로그인 활성화

공통 설정을 구성하여 kerberos를 단일 로그인 제공자로 추가하세요. 이렇게 하면 기존 GitLab 계정이 없는 사용자들을 위해 JIT(Just-In-Time) 계정 프로비저닝이 가능해집니다.

Kerberos 계정 생성 및 연결

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

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

관리자인 경우, Kerberos 계정을 기존의 GitLab 계정에 연결할 수 있습니다. 다음을 수행하세요:

  1. 왼쪽 사이드바에서 아래로 이동하여 관리를 선택합니다.
  2. 개요 > 사용자를 선택합니다.
  3. 사용자를 선택하고 아이덴티티 탭을 선택합니다.
  4. 제공자 드롭다운 목록에서 Kerberos를 선택합니다.
  5. 식별자가 Kerberos 사용자 이름과 일치하는지 확인합니다.
  6. 변경사항 저장을 선택합니다.

관리자가 아닌 경우:

  1. 왼쪽 사이드바에서 아바타를 선택합니다.
  2. 프로필 편집을 선택합니다.
  3. 왼쪽 사이드바에서 계정을 선택합니다.
  4. 서비스 로그인 섹션에서 Kerberos 연결을 선택합니다. 서비스 로그인에서 Kerberos 옵션이 표시되지 않는다면, 단일 로그인 활성화 요구 사항을 따르세요.

어느 쪽이든, 이제 Kerberos 자격 증명으로 GitLab 계정에 로그인할 수 있어야 합니다.

첫 번째 로그인 시 계정 생성

사용자가 Kerberos 계정으로 처음으로 GitLab에 로그인하면, GitLab에서 일치하는 계정을 만듭니다. 계속하기 전에 Omnibus 및 GitLab 소스의 공통 구성 설정 옵션을 검토해야 합니다. 여기에는 kerberos를 포함해야 합니다.

그런 다음:

  1. allow_single_sign_on 설정에 'kerberos'를 포함하세요.
  2. 현재는 기본 block_auto_created_users 옵션인 true를 수용하세요.
  3. 사용자가 Kerberos 자격 증명으로 로그인을 시도하면 GitLab이 새 계정을 만듭니다.

    1. block_auto_created_users가 true인 경우, Kerberos 사용자는 다음과 같은 메시지를 볼 수 있습니다. 

      계정이 차단되었습니다. 문제가 발생한 경우 GitLab 관리자에게 문의하세요.

      1. 관리자로서 새로 생성된 차단된 계정을 확인할 수 있습니다.

        1. 왼쪽 사이드바에서 아래로 이동하여 관리를 선택합니다.
        2. 왼쪽 사이드바에서 개요 > 사용자를 선택하고 차단됨 탭을 검토합니다.

      2. 사용자를 활성화할 수 있습니다.

    2. block_auto_created_users가 false인 경우, Kerberos 사용자가 인증되어 GitLab에 로그인합니다.

경고: block_auto_created_users의 기본값을 유지하는 것을 권장합니다. 관리자가 모르는 사이에 Kerberos 사용자가 GitLab에 계정을 생성할 경우 보안 위험이 될 수 있습니다.

Kerberos 및 LDAP 계정 연결

만약 사용자가 Kerberos로 로그인하지만 LDAP 통합이 활성화된 경우, 사용자는 첫 번째 로그인 시에 LDAP 계정에 연결됩니다. 이를 위해 몇 가지 사전 요구 사항이 충족되어야 합니다:

  • Kerberos 사용자 이름은 LDAP 사용자의 UID와 일치해아 합니다. GitLab LDAP 구성에서 UID로 사용될 LDAP 속성을 선택할 수 있지만, Active Directory의 경우 sAMAccountName이어야 합니다.
  • Kerberos 도메인은 LDAP 사용자의 Distinguished Name의 도메인 부분과 일치해아 합니다. 예를 들어 ‘Kerberos’ 도메인이 AD.EXAMPLE.COM인 경우, LDAP 사용자의 Distinguished Name은 dc=ad,dc=example,dc=com으로 끝나야 합니다.

이러한 규칙을 종합하면, 사용자의 Kerberos 사용자 이름 형식은 foo@AD.EXAMPLE.COM이어야 하며 사용자의 LDAP Distinguished Name은 sAMAccountName=foo,dc=ad,dc=example,dc=com과 같아야만 연결이 작동합니다.

사용자 정의 허용 도메인

사용자의 Kerberos 도메인이 사용자의 LDAP DN에서의 도메인과 일치하지 않는 경우 사용자 정의 허용 도메인을 구성할 수 있습니다. 구성 값은 사용자가 가질 수 있는 모든 도메인을 지정해야 합니다. 다른 도메인은 무시되고 LDAP identity가 연결되지 않습니다.

Linux package (Omnibus)

  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를 수행할 수 있습니다. 다시 말해, 각 작업마다 비밀번호를 보내지 않고도 가능합니다.

경고: libcurl 버전 7.64.1보다 오래된 버전에서는 연결을 재사용하지 않아 http.postBuffer 구성보다 큰 push 시 인가 문제가 발생하는 알려진 문제가 있습니다. 이를 피하려면 Git이 적어도 libcurl 7.64.1을 사용하고 있는지 확인하십시오. 설치된 libcurl 버전을 확인하려면 curl-config --version 명령을 실행하십시오.

Kerberos 토큰을 사용한 HTTP Git 접근 (비밀번호 인증 없음)

현재 Git 버전의 버그로 인해 git CLI 명령은 만약 HTTP 서버가 이를 제공한다면 네고시에이트 인증 방법만 사용합니다. 그러나 이 방법이 실패할 경우 (예: 클라이언트가 Kerberos 토큰이 없을 때) 임베디드 사용자 이름 및 비밀번호 (일명 기본이라고도 함) 인증으로 전환하는 것이 불가능합니다.

현재 Git 버전으로 기본 또는 네고시에이트 인증을 사용하게 하려면, 표준 포트에서는 기본 인증만 제공하고 다른 포트(예: 8443)에서 Kerberos 티켓 기반 인증을 제공하도록 설정할 수 있습니다.

참고: Git 2.4 및 이후의 버전은 사용자 이름과 비밀번호를 대화식 또는 자격 증명 관리자를 통해 전달할 때 기본 인증으로 전환을 지원합니다. URL의 일부로 사용자 이름과 비밀번호를 전달할 때는 전환하지 못합니다. 예를 들어, GitLab CI/CD 작업에서 CI/CD 작업 토큰으로 인증하는 경우가 있습니다.

Linux package (Omnibus)

  1. /etc/gitlab/gitlab.rb 파일 편집: 

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

  2. 변경사항이 적용되도록 GitLab을 재구성합니다.

직접 설치(소스) 및 HTTPS
  1. GitLab의 NGINX 구성 파일(예를 들어, /etc/nginx/sites-available/gitlab-ssl) 편집하고, 표준 HTTPS 포트 외에도 포트 8443에서 듣게끔 NGINX를 구성합니다: 
   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;

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

    kerberos:
  # Dedicated port: Git before 2.4 does not fall back to Basic authentication if Negotiate fails.
  # To support both Basic and Negotiate methods with older versions of Git, configure
  # nginx to proxy GitLab on an extra port (for example: 8443) and uncomment the following lines
  # to dedicate this port to Kerberos authentication. (default: false)
  use_dedicated_port: true
  port: 8443
  https: true

  2. 변경사항이 적용되도록 GitLab을 재시작하고 NGINX를 재시작합니다.

이 변경 후 Git 원격 URL을 업데이트하여 https://gitlab.example.com:8443/mygroup/myproject.git를 사용하여 Kerberos 티켓 기반 인증을 사용할 수 있습니다.

패스워드 기반에서 티켓 기반 Kerberos 로그인으로 업그레이드

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

우리는 GitLab 15.0에서 패스워드 기반 Kerberos 로그인을 제거했습니다.

Active Directory Kerberos 환경 지원

Active Directory 도메인에서 티켓 기반 인증을 사용할 때, Kerberos 프로토콜의 확장으로 인해 기본 크기인 8 kB보다 큰 HTTP 인증 헤더가 발생할 수 있으므로 NGINX가 허용하는 최대 헤더 크기를 증가시키는 것이 필요할 수 있습니다. NGINX 구성에서 large_client_header_buffers를 더 큰 값으로 구성하십시오.

Windows AD에서 AES만을 이용한 Keytab 사용

고급 암호화 표준(Advanced Encryption Standard, AES)만을 이용한 keytab을 생성할 때, AD 서버에서 해당 계정에 대해 이 계정은 Kerberos AES <128/256>비트 암호화를 지원 확인란을 선택해야 합니다. 확인란이 128비트인지 256비트인지는 키탭을 생성할 때 사용한 암호화 강도에 따라 달라집니다. 확인하려면 Active Directory 서버에서 다음을 수행하세요:

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