InfoGrab DocsInfoGrab Docs

Spamcheck 안티스팸 서비스

요약

Spamcheck는 모든 티어에서 제공되지만, GitLab Enterprise Edition(EE)을 사용하는 인스턴스에서만 동작합니다. Spamcheck는 GitLab.com에서 늘어나는 스팸에 대응하기 위해 GitLab 이 개발한 안티스팸 엔진이며, 이후 GitLab Self-Managed 인스턴스에서도 사용할 수 있도록 공개되었습니다.

Warning

Spamcheck는 모든 티어에서 제공되지만, GitLab Enterprise Edition(EE)을 사용하는 인스턴스에서만 동작합니다. 라이선스 문제로 GitLab Community Edition(CE) 패키지에는 포함되지 않습니다. CE에서 EE로 마이그레이션할 수 있습니다.

Spamcheck는 GitLab.com에서 늘어나는 스팸에 대응하기 위해 GitLab 이 개발한 안티스팸 엔진이며, 이후 GitLab Self-Managed 인스턴스에서도 사용할 수 있도록 공개되었습니다.

Spamcheck 활성화#

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

  1. /etc/gitlab/gitlab.rb를 편집해 Spamcheck를 활성화합니다.

    spamcheck['enable'] = true

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

    sudo gitlab-ctl reconfigure

  3. 새 서비스 spamcheck와 spam-classifier가 정상적으로 실행 중인지 확인합니다.

    sudo gitlab-ctl status

Spamcheck를 사용하도록 GitLab 구성#

사전 요구 사항:

  • 관리자 접근 권한.
  1. 오른쪽 위에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > Reporting을 선택합니다.
  3. Spam and Anti-bot Protection을 확장합니다.
  4. Spam Check 설정을 갱신합니다.
    1. "Enable Spam Check via external API endpoint" 체크박스를 선택합니다.
    2. URL of the external Spam Check endpoint에는 grpc://localhost:8001을 사용합니다.
    3. Spam Check API key는 비워 둡니다.
  5. Save changes를 선택합니다.
Note

단일 노드 인스턴스에서 Spamcheck는 localhost를 통해 실행되므로 인증 없이 동작합니다. GitLab 이 한 서버에서 실행되고 Spamcheck가 공개 엔드포인트를 수신 대기하는 다른 서버에서 실행되는 다중 노드 인스턴스라면, Spamcheck 서비스 앞에 역방향 프록시를 두고 API 키와 함께 사용하는 방식으로 인증을 강제하기를 권장합니다. 예를 들어 JWT 인증을 사용하고 bearer 토큰을 API 키로 지정하는 방법을 들 수 있습니다. Spamcheck 자체 인증 기능은 개발 중입니다.

TLS를 통한 Spamcheck 실행#

Spamcheck 서비스 자체는 GitLab과 TLS로 직접 통신하지 못합니다. 다만 TLS 종료를 처리하는 역방향 프록시 뒤에 Spamcheck를 배포할 수 있습니다. 이 경우 Admin 영역 설정에서 외부 Spamcheck URL의 스키마를 grpc:// 대신 tls://로 지정하면 GitLab 이 TLS를 통해 Spamcheck와 통신하도록 구성할 수 있습니다.

Spamcheck 안티스팸 서비스

GitLab v19.5
Tier: Free, Premium, Ultimate
Offering: GitLab Self-Managed
원문 보기

요약

Spamcheck는 모든 티어에서 제공되지만, GitLab Enterprise Edition(EE)을 사용하는 인스턴스에서만 동작합니다. Spamcheck는 GitLab.com에서 늘어나는 스팸에 대응하기 위해 GitLab 이 개발한 안티스팸 엔진이며, 이후 GitLab Self-Managed 인스턴스에서도 사용할 수 있도록 공개되었습니다.

Warning

Spamcheck는 모든 티어에서 제공되지만, GitLab Enterprise Edition(EE)을 사용하는 인스턴스에서만 동작합니다. 라이선스 문제로 GitLab Community Edition(CE) 패키지에는 포함되지 않습니다. CE에서 EE로 마이그레이션할 수 있습니다.

Spamcheck는 GitLab.com에서 늘어나는 스팸에 대응하기 위해 GitLab 이 개발한 안티스팸 엔진이며, 이후 GitLab Self-Managed 인스턴스에서도 사용할 수 있도록 공개되었습니다.

Spamcheck 활성화#

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

  1. /etc/gitlab/gitlab.rb를 편집해 Spamcheck를 활성화합니다.

    spamcheck['enable'] = true

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

    sudo gitlab-ctl reconfigure

  3. 새 서비스 spamcheck와 spam-classifier가 정상적으로 실행 중인지 확인합니다.

    sudo gitlab-ctl status

Spamcheck를 사용하도록 GitLab 구성#

사전 요구 사항:

  • 관리자 접근 권한.
  1. 오른쪽 위에서 Admin을 선택합니다.
  2. 왼쪽 사이드바에서 Settings > Reporting을 선택합니다.
  3. Spam and Anti-bot Protection을 확장합니다.
  4. Spam Check 설정을 갱신합니다.
    1. "Enable Spam Check via external API endpoint" 체크박스를 선택합니다.
    2. URL of the external Spam Check endpoint에는 grpc://localhost:8001을 사용합니다.
    3. Spam Check API key는 비워 둡니다.
  5. Save changes를 선택합니다.
Note

단일 노드 인스턴스에서 Spamcheck는 localhost를 통해 실행되므로 인증 없이 동작합니다. GitLab 이 한 서버에서 실행되고 Spamcheck가 공개 엔드포인트를 수신 대기하는 다른 서버에서 실행되는 다중 노드 인스턴스라면, Spamcheck 서비스 앞에 역방향 프록시를 두고 API 키와 함께 사용하는 방식으로 인증을 강제하기를 권장합니다. 예를 들어 JWT 인증을 사용하고 bearer 토큰을 API 키로 지정하는 방법을 들 수 있습니다. Spamcheck 자체 인증 기능은 개발 중입니다.

TLS를 통한 Spamcheck 실행#

Spamcheck 서비스 자체는 GitLab과 TLS로 직접 통신하지 못합니다. 다만 TLS 종료를 처리하는 역방향 프록시 뒤에 Spamcheck를 배포할 수 있습니다. 이 경우 Admin 영역 설정에서 외부 Spamcheck URL의 스키마를 grpc:// 대신 tls://로 지정하면 GitLab 이 TLS를 통해 Spamcheck와 통신하도록 구성할 수 있습니다.