스팸체크 방지 서비스

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 인스턴스에서 사용할 수 있도록 공개되었습니다.

스팸체크 활성화

스팸체크는 패키지 기반 설치에만 사용할 수 있습니다:

  1. /etc/gitlab/gitlab.rb를 편집하여 스팸체크를 활성화합니다: 

    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
싱글 노드 인스턴스에서는 스팸체크가 localhost에서 실행되므로 인증되지 않은 모드로 실행됩니다. 여러 노드 인스턴스에서 GitLab이 하나의 서버에서 실행되고 스팸체크가 다른 서버에서 공개 엔드포인트를 통해 수신 대기하는 경우, 스팸체크 서비스 앞에 리버스 프록시를 사용하여 어떤 형태의 인증을 강제하는 것이 권장됩니다. 예를 들어, 이를 위해 JWT 인증을 사용하고 API 키로 사용할 수 있는 베어러 토큰을 지정하는 것이 있습니다. 스팸체크의 네이티브 인증이 준비 중입니다.

TLS로 스팸체크 실행

스팸체크 서비스 자체는 TLS를 통해 GitLab과 직접 통신할 수 없습니다. 그러나 스팸체크는 TLS 종료를 수행하는 리버스 프록시 뒤에 배포될 수 있습니다. 이러한 시나리오에서는 Admin Area 설정에서 외부 스팸체크 URL에 tls:// scheme을 지정함으로써 GitLab이 TLS를 통해 스팸체크와 통신할 수 있습니다. grpc:// 대신에.