InfoGrab 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. 설정 > 보고를 선택합니다.
  3. 스팸 및 봇 방지를 확장합니다.
  4. 스팸 검사 설정을 업데이트합니다:
    1. "외부 API 엔드포인트를 통한 스팸 검사 활성화" 체크박스를 선택합니다.
    2. 외부 스팸 검사 엔드포인트 URL에 grpc://localhost:8001을 사용합니다.
    3. 스팸 검사 API 키는 비워둡니다.
  5. 변경 사항 저장을 선택합니다.
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와 통신하도록 만들 수 있습니다.

Spamcheck 안티스팸 서비스

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. 설정 > 보고를 선택합니다.
  3. 스팸 및 봇 방지를 확장합니다.
  4. 스팸 검사 설정을 업데이트합니다:
    1. "외부 API 엔드포인트를 통한 스팸 검사 활성화" 체크박스를 선택합니다.
    2. 외부 스팸 검사 엔드포인트 URL에 grpc://localhost:8001을 사용합니다.
    3. 스팸 검사 API 키는 비워둡니다.
  5. 변경 사항 저장을 선택합니다.
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와 통신하도록 만들 수 있습니다.