Spamcheckアンチスパムサービス

プラン: Free、Premium、Ultimate
提供形態: GitLab Self-Managed

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を設定する

左側のサイドバーの下部で、管理者を選択します。
左側のサイドバーの下部にある設定 > レポートを選択します。
スパムとアンチボット対策を展開します。
スパムチェック設定を更新します:
1. 「外部APIエンドポイント経由でスパムチェックを有効にする」チェックボックスをオンにします。
2. 外部スパムチェックエンドポイントのURLには、grpc://localhost:8001を使用します。
3. スパムチェックAPIキーは空白のままにします。
変更を保存を選択します。

シングルノードのインスタンスでは、Spamcheckはlocalhostを介して実行されるため、認証されていないモードで実行されています。マルチノードインスタンスで、GitLabが1つのサーバーで実行され、Spamcheckがパブリックエンドポイントを介してリッスンする別のサーバーで実行されている場合は、APIキーとともに使用できるSpamcheckサービスの前にリバースプロキシを使用して、何らかの種類の認証を適用することをお勧めします。1つの例としては、これにJWT認証を使用し、ベアラートークンをAPIキーとして指定することが挙げられます。Spamcheckのネイティブ認証が進行中です。

TLS経由でのSpamcheckの実行

Spamcheckサービス自体は、TLS経由でGitLabと直接通信できません。ただし、Spamcheckは、TLS終端を実行するリバースプロキシの背後にデプロイできます。このようなシナリオでは、管理者エリアの設定で、grpc://の代わりに外部SpamcheckのURLにtls://スキームを指定することで、GitLabがTLS経由でSpamcheckと通信できるようになります。