GitLab과 Kerberos 통합

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

GitLab은 인증 메커니즘으로 Kerberos를 사용할 수 있습니다.

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

Kerberos는 GitLab Enterprise Edition (EE)를 사용하는 인스턴스에서만 사용할 수 있습니다. Kerberos를 사용하려면 다음 중 하나를 수행할 수 있습니다.

caution
Kerberos를 사용하는 GitLab 인스턴스에서는 GitLab CI/CD가 별도의 포트를 사용하도록 설정되지 않는 한 작동하지 않습니다. (#http-git-access-with-kerberos-token-passwordless-authentication)

구성

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 젬 그룹이 설치되었는지 확인합니다.

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

    omniauth:
  enabled: true
  allow_single_sign_on: ['kerberos']
   
kerberos:
  # Git 클라이언트를 위한 HTTP 네고셔에이션 인증 방법 허용
  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 액세스에 대한 네고시에이트 인증 방법을 제공하여 이 인증 프로토콜을 지원하는 Git 클라이언트가 Kerberos 토큰으로 인증할 수 있습니다.

단일 로그인 활성화

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

Kerberos 계정 생성 및 연결

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

기존 GitLab 계정에 Kerberos 계정 연결

-GitLab 15.4에서 Kerberos SPNEGO가 Kerberos로 변경되었습니다.

관리자인 경우 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에 로그인됩니다.

caution
block_auto_created_users의 기본값을 유지하는 것이 좋습니다. 관리자가 모르는 채로 Kerberos 사용자가 GitLab에 계정을 생성하면 보안 문제가 발생할 수 있습니다.

Kerberos 및 LDAP 계정 연결

사용자가 Kerberos로 로그인하지만 LDAP 통합을 사용하는 경우 첫 번째 로그인에서 사용자는 LDAP 계정에 연결됩니다. 이 작업을 위해 일부 사전 조건을 충족해야 합니다.

Kerberos 사용자 이름은 LDAP 사용자의 UID와 일치해야 합니다. GitLab LDAP 구성에서 LDAP 속성 중 어떤 것이 UID로 사용되는지 선택할 수 있지만, 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 식별이 연결되지 않습니다.

Linux 패키지(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도 할 수 있습니다. 즉, 각 작업마다 비밀번호를 보내지 않아도됩니다.

caution
libcurl 버전 7.64.1보다 오래 된 버전에서는 알려진 문제로 인해 협상 중에 연결을 재사용하지 않으므로 http.postBuffer 구성을 초과하는 큰 push에서 인가 문제가 발생합니다. 이를 피하려면 Git이 적어도 libcurl 7.64.1을 사용하고 있는지 확인하세요. 설치된 libcurl 버전을 확인하려면 curl-config --version을 실행하세요.

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

현재 Git 버전의 버그로 인해 git CLI 명령은 HTTP 서버가 제공하는 경우에만 negotiate 인증 방법을 사용합니다. 심지어 이 방법이 실패해도(예: 클라이언트에 Kerberos 토큰이 없는 경우) basic 인증으로 떨어지지 않습니다. 따라서 Kerberos 인증에 실패하면 (기본적으로 알려진) 내장된 사용자 이름 및 암호(또는 basic 인증)으로 돌아갈 수 없습니다.

현재 Git 버전과 함께 basic 또는 negotiate 인증을 사용할 수 있도록 GitLab 사용자에게 Kerberos 티켓 기반 인증을 제공하는 것이 가능합니다. 이를 위해 기본 포트(예: 8443)에서는 basic 인증만을 제공하고 다른 포트에서는 Kerberos 티켓 기반 인증을 제공할 수 있습니다.

note
Git 2.4 이상에서는 대화식 또는 자격 증명 관리자를 통해 사용자 이름과 암호가 전달되면 basic 인증으로 되돌아가도록 지원합니다. 그러나 URL의 일부로 사용자 이름과 암호가 전달되면 되돌아가지 못합니다. 이것은 예를 들어 GitLab CI/CD 작업에서 CI/CD 작업 토큰으로 인증하는 경우에 발생할 수 있습니다.
Linux 패키지(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;

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

  3. 변경 사항이 적용되도록 GitLab 및 NGINX를 다시 시작하세요.

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

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

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

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

Active Directory Kerberos 환경 지원

Active Directory 도메인에서 Kerberos 티켓 기반 인증을 사용할 때 NGINX에서 허용된 최대 해더 크기를 늘려야 할 수 있습니다. Kerberos 프로토콜의 확장으로 인해 HTTP 인증 해더가 기본 8 KB의 크기보다 크게 될 수 있습니다. NGINX 구성에서 large_client_header_buffers를 더 큰 값으로 구성하세요.

Windows AD에서 AES-only 암호화를 사용하는 Keytab 사용

고급 암호화 표준(AES)-only 암호화로 키탭을 만들 때 해당 계정에서 이 계정은 Kerberos AES <128/256> bit 암호화를 지원합니다 확인란을 선택해야합니다. 확인란은 키탭을 작성할 때 사용한 암호화 강도에 따라 128 비트 또는 256 비트 일 수 있습니다. 이를 확인하려면 Active Directory 서버에서:

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