스팸확인 안티스팸 서비스

Tier: Free, Premium, Ultimate Offering: Self-Managed
caution
스팸확인은 모든 티어에서 사용할 수 있지만, GitLab Enterprise Edition (EE)를 사용하는 인스턴스에서만 사용할 수 있습니다. 라이선스 이유로, GitLab Community Edition (CE) 패키지에는 포함되어 있지 않습니다. CE에서 EE로 마이그레이션할 수 있습니다.

스팸확인은 GitLab에서 스팸이 증가함에 따라 처음에는 GitLab.com에서 스팸을 줄이기 위해 개발되었으며, 나중에는 Self-Managed GitLab 인스턴스에서 사용할 수 있도록 공개되었습니다.

스팸확인 활성화

스팸확인은 패키지 기반 설치에서만 사용할 수 있습니다:

  1. /etc/gitlab/gitlab.rb 파일을 편집하고 스팸확인을 활성화합니다: 

    spamcheck['enable'] = true

  2. GitLab을 다시 구성합니다: 

    sudo gitlab-ctl reconfigure

  3. 새 서비스 spamcheck 및 spam-classifier이 실행 중인지 확인합니다: 

    sudo gitlab-ctl status

GitLab을 스팸확인 사용하도록 구성

  1. 왼쪽 사이드바에서 Admin을 선택합니다.
  2. Settings > Reporting을 선택합니다.
  3. Spam and Anti-bot Protection을 확장합니다.
  4. 스팸 확인 설정을 업데이트합니다:
    1. “외부 API 엔드포인트를 통한 스팸 확인 활성화” 확인란을 선택합니다.
    2. 외부 스팸 확인 엔드포인트 URL에 grpc://localhost:8001을 사용합니다.
    3. 스팸 확인 API 키는 비워둡니다.
  5. 변경 사항 저장을 선택합니다.
note
단일 노드 인스턴스의 경우, 스팸확인은 localhost를 통해 실행되므로 인증되지 않은 모드로 실행됩니다. GitLab이 한 서버에서 실행되고 스팸확인이 공개 엔드포인트에서 수신 대기하는 다중 노드 인스턴스의 경우, Spamcheck 서비스 앞에 역방향 프록시를 통해 어떤 형식의 인증을 강제하는 것이 권장됩니다. 이를 위해 JWT 인증을 사용하고 API 키로 토큰을 지정할 수 있습니다. 예를 들어, 스팸확인을 위한 네이티브 인증이 진행 중입니다.

TLS를 통한 스팸확인 실행

스팸확인 서비스는 자체적으로 직접 TLS를 통해 GitLab과 통신할 수 없습니다. 그러나 TLS 종료를 수행하는 역방향 프록시 뒤에 스팸확인을 배포할 수 있습니다. 이러한 시나리오에서 관리자 영역 설정에서 외부 스팸확인 URL에 grpc:// 대신 tls:// 체계를 지정함으로써 GitLab이 TLS를 통해 스팸확인과 통신하도록 할 수 있습니다.