debian-mirror-gitlab/doc/user/admin_area/reporting/spamcheck.md

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

69 lines
2.8 KiB
Markdown
Raw Normal View History

2022-04-04 11:22:00 +05:30
---
2022-07-23 23:45:48 +05:30
stage: Systems
2022-04-04 11:22:00 +05:30
group: Distribution
2022-05-07 20:08:51 +05:30
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
2022-04-04 11:22:00 +05:30
---
2022-05-07 20:08:51 +05:30
# Spamcheck anti-spam service **(FREE SELF)**
2022-04-04 11:22:00 +05:30
> [Introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6259) in GitLab 14.8.
2022-05-07 20:08:51 +05:30
WARNING:
Spamcheck is available to all tiers, but only on instances using GitLab Enterprise Edition (EE). For [licensing reasons](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6259#note_726605397), it is not included in the GitLab Community Edition (CE) package. You can [migrate from CE to EE](../../../update/package/convert_to_ee.md).
2022-04-04 11:22:00 +05:30
[Spamcheck](https://gitlab.com/gitlab-org/spamcheck) is an anti-spam engine
developed by GitLab originally to combat rising amount of spam in GitLab.com,
and later made public to be used in self-managed GitLab instances.
## Enable Spamcheck
Spamcheck is only available for package-based installations:
1. Edit `/etc/gitlab/gitlab.rb` and enable Spamcheck:
```ruby
spamcheck['enable'] = true
```
1. Reconfigure GitLab:
```shell
sudo gitlab-ctl reconfigure
```
1. Verify that the new services `spamcheck` and `spam-classifier` are
up and running:
```shell
sudo gitlab-ctl status
```
## Configure GitLab to use Spamcheck
1. On the top bar, select **Menu > Admin**.
1. On the left sidebar, select **Settings > Reporting**.
1. Expand **Spam and Anti-bot Protection**.
1. Update the Spam Check settings:
1. Check the "Enable Spam Check via external API endpoint" checkbox.
1. For **URL of the external Spam Check endpoint** use `grpc://localhost:8001`.
1. Leave **Spam Check API key** blank.
1. Select **Save changes**.
NOTE:
2022-05-07 20:08:51 +05:30
In single-node instances, Spamcheck runs over `localhost`, and hence is running
2022-04-04 11:22:00 +05:30
in an unauthenticated mode. If on multi-node instances where GitLab runs on one
server and Spamcheck runs on another server listening over a public endpoint, it
is recommended to enforce some sort of authentication using a reverse proxy in
front of the Spamcheck service that can be used along with an API key. One
example would be to use `JWT` authentication for this and specifying a bearer
token as the API key.
[Native authentication for Spamcheck is in the works](https://gitlab.com/gitlab-com/gl-security/engineering-and-research/automation-team/spam/spamcheck/-/issues/171).
## Running Spamcheck over TLS
Spamcheck service on its own can not communicate directly over TLS with GitLab.
However, Spamcheck can be deployed behind a reverse proxy which performs TLS
termination. In such a scenario, GitLab can be made to communicate with
Spamcheck over TLS by specifying `tls://` scheme for the external Spamcheck URL
2022-07-16 23:28:13 +05:30
instead of `grpc://` in the Admin Area settings.