スパムチェック

GitLab 14.8で導入されました。

caution
Spamcheckは全ての階層で利用可能ですが、GitLab Enterprise Edition(EE)を使用しているインスタンスでのみ利用可能です。ライセンスの都合上、GitLab Community Edition(CE) パッケージには含まれていません。CEからEEへのマイグレーションが可能です。

Spamcheckは、もともとGitLab.comで増加するスパムに対抗するためにGitLabによって開発されたアンチスパムエンジンで、後にセルフマネージドGitLabインスタンスで使えるように公開されました。

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

GitLabでスパムチェックを使う設定

  1. 左のサイドバーで、Search を選択するか、次のページに進んでください。
  2. Admin Areaを選択します。
  3. 設定 > レポートを選択します。
  4. スパムとボット対策を展開します。
  5. スパムチェックの設定を更新します：
    1. Enable Spam Check via external API endpoint” チェックボックスをチェックしてください。
    2. 外部スパムチェックエンドポイントのURLは grpc://localhost:8001 を使用してください。
    3. スパムチェックAPIキーは空白のままにしてください。
  6. 変更を保存を選択します。
note
シングルノードインスタンスでは、Spamcheck はlocalhost 上で実行されるため、認証されていないモードで実行されます。マルチノードインスタンスで GitLab があるサーバー上で動作し、Spamcheck が公開エンドポイントをリッスンしている別のサーバー上で動作している場合は、Spamcheck サービスの前にリバースプロキシを使って何らかの認証を行うことを推奨します。一例として、JWT 認証を使用し、API キーとしてベアラートークンを指定する方法があります。Spamcheckのネイティブ認証は現在準備中です。

TLS経由でのSpamcheckの実行

Spamcheckサービス単体では、GitLabとTLSで直接通信することはできません。しかし、SpamcheckはTLSターミネーションを行うリバースプロキシの後ろにデプロイすることができます。そのようなシナリオでは、管理エリアの設定で外部のSpamcheck URLにgrpc:// の代わりにtls:// schemeを指定することで、GitLabとSpamcheckをTLSで通信させることができます。