GitLab과 Kerberos 통합

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

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

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

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

구성

GitLab이 Kerberos 기반 토큰 인증을 제공하도록 하려면 다음의 전제 조건을 수행하십시오. Kerberos 사용을 위해 시스템을 구성해야 하며, 예를 들어 realm을 지정하는 것과 같습니다. GitLab은 시스템의 Kerberos 설정을 사용합니다.

GitLab keytab

  1. GitLab 서버의 HTTP 서비스용 Kerberos 서비스 주체를 생성합니다.
    GitLab 서버가 gitlab.example.com이고 Kerberos realm이 EXAMPLE.COM인 경우, Kerberos 데이터베이스에 HTTP/gitlab.example.com@EXAMPLE.COM 서비스 주체를 생성합니다.

  2. 위의 서비스 주체를 위해 GitLab 서버에 keytab를 생성합니다. 예를 들어,
    /etc/http.keytab.

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

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

GitLab 구성

셀프 컴파일 설치

note
셀프 컴파일 설치의 경우, kerberos gem 그룹이 설치되어 있는지 확인하십시오.

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

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

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

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

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

리눅스 패키지 설치

  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 토큰으로 인증할 수 있습니다.

SSO(싱글 사인온) 활성화

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

케르베로스 계정 생성 및 연결

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

기존 GitLab 계정에 Kerberos 계정 연결

  • Kerberos SPNEGO는 GitLab 15.4에서 Kerberos로 이름 변경되었습니다.

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

  1. 왼쪽 사이드바의 하단에서 관리자를 선택합니다.
  2. 개요 > 사용자를 선택합니다.
  3. 사용자를 선택한 다음 신원 탭을 선택합니다.
  4. 공급자 드롭다운 목록에서 Kerberos를 선택합니다.
  5. 식별자가 Kerberos 사용자 이름과 일치하는지 확인합니다.
  6. 변경 사항 저장을 선택합니다.

관리자가 아닌 경우:

  1. 왼쪽 사이드바에서 아바타를 선택합니다.
  2. 프로필 편집을 선택합니다.
  3. 왼쪽 사이드바에서 계정을 선택합니다.
  4. 서비스 로그인 섹션에서 Kerberos 연결을 선택합니다. 서비스 로그인 Kerberos 옵션이 보이지 않으면, SSO(싱글 사인온) 활성화에 있는 요구 사항을 따르십시오.

두 경우 모두 이제 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의 기본값을 유지하는 것이 좋습니다.

관리자의 지식 없이 GitLab에서 계정을 생성하는 Kerberos 사용자는 보안 위험이 될 수 있습니다.

Kerberos 및 LDAP 계정을 함께 연결

사용자가 Kerberos로 로그인하지만, LDAP 통합이 활성화되어 있는 경우, 사용자는 첫 로그인 시 LDAP 계정에 연결됩니다.

이 기능이 작동하려면 몇 가지 전제 조건이 충족되어야 합니다:

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

Kerberos 영역은 LDAP 사용자의 고유 식별 이름의 도메인 부분과 일치해야 합니다. 예를 들어, 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 아이덴티티가 연결되지 않습니다.

리눅스 패키지 (Omnibus)

  1. /etc/gitlab/gitlab.rb 파일을 편집합니다:

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

  2. 파일을 저장하고 재구성하여 변경 사항이 적용되도록 합니다.

직접 컴파일 (소스)

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

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

  2. 파일을 저장하고 재시작하여 변경 사항이 적용되도록 합니다.

HTTP Git 접근

연결된 Kerberos 계정은 Kerberos 계정뿐만 아니라 일반 GitLab 자격 증명을 사용하여 git pull 및 git push를 할 수 있습니다.

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

경고: libcurl 7.64.1 이전 버전에는 연결을 재사용하지 않는 알려진 문제가 있습니다. 이는 푸시가 http.postBuffer 구성보다 클 때 권한 부여 문제를 일으킵니다. 이를 피하려면 최소한 libcurl 7.64.1 을 사용해야 합니다. 설치된 libcurl 버전을 확인하려면 curl-config --version을 실행하세요.

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

현재 Git 버전의 버그 때문에, git CLI 명령은 HTTP 서버가 제공하는 경우에만 negotiate 인증 방법을 사용하며, 이 방법이 실패하는 경우(예: 클라이언트가 Kerberos 토큰을 가지고 있지 않을 때)에도 계속해서 사용됩니다. Kerberos 인증이 실패할 경우 내장된 사용자 이름 및 비밀번호(기본 인증이라고도 함)로 되돌아갈 수 없습니다.

현재 Git 버전에서 GitLab 사용자가 basic 또는 negotiate 인증을 모두 사용할 수 있도록, 표준 포트는 basic 인증만 제공하고 Kerberos 티켓 기반 인증은 다른 포트(예: 8443)에서 제공할 수 있습니다.

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

리눅스 패키지 (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:
  # 전용 포트: Git 2.4 이전 버전은 Negotiate가 실패할 경우 기본 인증으로 되돌아가지 않습니다.
  # 이전 Git 버전에서 기본 및 Negotiate 방법을 모두 지원하려면
  # NGINX가 GitLab을 추가 포트(예: 8443)에서 프록시하도록 구성하고,
  # Kerberos 인증에 이 포트를 전용하기 위해 다음 줄의 주석을 제거합니다. (기본값: 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에 제출해야 했습니다.

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

Active Directory Kerberos 환경 지원

Active Directory 도메인에서 Kerberos 티켓 기반 인증을 사용할 때, NGINX에서 허용되는 최대 헤더 크기를 늘릴 필요가 있을 수 있습니다. Kerberos 프로토콜에 대한 확장이 기본 크기인 8 kB보다 큰 HTTP 인증 헤더를 초래할 수 있습니다. NGINX 구성에서 large_client_header_buffers를 더 큰 값으로 설정하세요.

Windows AD와 함께 AES 전용 암호화로 생성된 Keytabs 사용

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

  1. 사용자 및 그룹 도구를 엽니다.

  2. keytab을 생성하는 데 사용한 계정을 찾습니다.

  3. 해당 계정을 마우스 오른쪽 버튼으로 클릭하고 속성을 선택합니다.

  4. 계정 탭의 계정 옵션에서 적절한 AES 암호화 지원 체크박스를 선택합니다.

  5. 저장하고 닫습니다.