Allow admins to block Pages sites for a project or group
Problem to solve
Currently, managing abuse of the Pages service is a manual process. This is no good built-in way to block a particular Pages site from being served. An issue about this from gl-infra: https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/6060
Target audience
-
Sidney, Systems Administrator, https://design.gitlab.com/research/personas#persona-sidney
-
Sam, Security Analyst, https://design.gitlab.com/research/personas#persona-sam
Further details
Currently, our sysadmins have to apply and manage Pages blocks manually, using a variety of sub-optimal methods. This isn't transparent to other admins, and doesn't scale in general.
Proposal
Allow administrators to press a button in the UI to "block" a Pages site - or all the pages in an entire namespace. This "blocked" status will be filtered through to the configuration data for a particular pages site, while leaving the pages untouched on disk. When the Pages daemon comes to serve a "blocked" site, it can consult the configutation and refuse to serve the content with a 5xx (or perhaps 451) error response.
Currently, this configuration data takes ~15 minutes to rebuild, which is not ideal. However, it's still easier than editing and deploying a haproxy config file across all nodes. A progressive enhancement to this issue occurs when we implement gitlab-pages#161 (closed) - blocked statuses will propagate much more quickly.
When I say "pages site", I mean the site, plus all of its custom domains. I don't think there's any need to allow some custom domains to work, while others fail. A possible edge case might be an offensive custom domain (waffen.ss
, for instance) - but I expect that's almost always going to be twinned with offensive content.
What does success look like, and how can we measure that?
Systems administrators and security analysts can quickly respond to a report of Pages abuse in the GitLab UI to cause bad pages sites to become unavailable.
Links / references
cc @nolith @mkozono @jarv @andrewn @jlenny @jritchey @jurbanc
I don't know if we want to label this with gitlab-ce3608049 and/or gitlab-ce8527302 , it seems like something we could use on GitLab.com, like, yesterday :D