스팸 확인 안티 스팸 서비스

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

Spamcheck은 GitLab이 처음에는 GitLab.com의 스팸 증가에 대응하기 위해 개발한 안티 스팸 엔진으로, 나중에는 Self-Managed형 GitLab 인스턴스에서 사용할 수 있도록 공개되었습니다.

스팸확인 활성화

Spamcheck은 패키지 기반 설치에서만 사용할 수 있습니다.

  1. /etc/gitlab/gitlab.rb을 수정하고 Spamcheck을 활성화합니다: 

    spamcheck['enable'] = true

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

    sudo gitlab-ctl reconfigure

  3. 새로운 서비스 spamcheck와 spam-classifier가 실행 중인지 확인합니다: 

    sudo gitlab-ctl status

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

  1. 왼쪽 사이드바에서 맨 아래에서 관리 영역을 선택합니다.
  2. 설정 > 보고를 선택합니다.
  3. 스팸 및 안티 봇 보호를 확장합니다.
  4. 스팸 확인 설정을 업데이트합니다:
    1. “외부 API 엔드포인트를 통한 스팸 확인 활성화” 확인란을 선택합니다.
    2. 외부 스팸 확인 엔드포인트 URL에 grpc://localhost:8001을 사용합니다.
    3. 스팸 확인 API 키는 비워둡니다.
  5. 변경 사항 저장을 선택합니다.
note
단일 노드 인스턴스의 경우 Spamcheck은 localhost를 통해 실행되므로 인증되지 않은 상태로 실행됩니다. GitLab이 한 서버에서 실행되고 Spamcheck이 다른 서버에서 공개 엔드포인트를 통해 실행되는 멀티 노드 인스턴스의 경우, Spamcheck 서비스 앞에 역방향 프록시를 사용하여 인증을 강제하는 것이 권장됩니다. 이를 위해 JWT 인증을 사용하고 API 키로 베어러 토큰을 지정할 수 있습니다. Spamcheck의 네이티브 인증이 진행 중입니다.

TLS를 통한 Spamcheck 실행

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