Spamcheck 안티스팸 서비스

GitLab Self-Managed 인스턴스에서 Spamcheck 안티스팸 엔진을 구성하고 사용하는 방법을 설명합니다.

Warning Spamcheck는 모든 티어에서 사용 가능하지만 GitLab Enterprise Edition(EE)을 사용하는 인스턴스에서만 작동합니다. 라이선스 이유 로 GitLab Community Edition(CE) 패키지에는 포함되지 않습니다. CE에서 EE로 마이그레이션 할 수 있습니다. Spamcheck 는 원래 GitLab.com의 급증하는 스팸에 대응하기 위해 GitLab에서 개발한 안티스팸 엔진으로, 이후 GitLab Self-Managed 인스턴스에서 사용할 수 있도록 공개되었습니다. Spamcheck 활성화 # Spamcheck는 패키지 기반 설치에서만 사용할 수 있습니다: /etc/gitlab/gitlab.rb 를 편집하고 Spamcheck를 활성화합니다: spamcheck[ 'enable' ] = true GitLab을 다시 구성합니다: sudo gitlab-ctl reconfigure 새 서비스 spamcheck 및 spam-classifier 가 실행 중인지 확인합니다: sudo gitlab-ctl status Spamcheck를 사용하도록 GitLab 구성 # 전제 조건: 관리자 접근 권한. 오른쪽 상단에서 Admin 을 선택합니다. 설정 > 보고 를 선택합니다. 스팸 및 봇 방지 를 확장합니다. 스팸 검사 설정을 업데이트합니다: "외부 API 엔드포인트를 통한 스팸 검사 활성화" 체크박스를 선택합니다. 외부 스팸 검사 엔드포인트 URL 에 grpc://localhost:8001 을 사용합니다. 스팸 검사 API 키 는 비워둡니다. 변경 사항 저장 을 선택합니다. Note 단일 노드 인스턴스에서는 Spamcheck가 localhost 에서 실행되므로 인증 없이 실행됩니다. GitLab이 한 서버에서 실행되고 Spamcheck가 공개 엔드포인트에서 수신 대기하는 다른 서버에서 실행되는 다중 노드 인스턴스에서는 API 키와 함께 사용할 수 있는 역방향 프록시를 Spamcheck 서비스 앞에 사용하여 일종의 인증을 강제하는 것이 권장됩니다. 한 가지 예는 이를 위해 JWT 인증을 사용하고 API 키로 bearer 토큰을 지정하는 것입니다. Spamcheck를 위한 기본 인증은 개발 중 입니다. TLS를 통한 Spamcheck 실행 # Spamcheck 서비스 자체는 GitLab과 직접 TLS를 통해 통신할 수 없습니다. 그러나 Spamcheck는 TLS 종료를 수행하는 역방향 프록시 뒤에 배포할 수 있습니다. 이러한 시나리오에서 Admin 영역 설정에서 외부 Spamcheck URL에 grpc:// 대신 tls:// 스키마를 지정하여 GitLab이 TLS를 통해 Spamcheck와 통신하도록 만들 수 있습니다.