The readiness endpoint of the GitLab Pages feature of .com is exposed to the wider Internet
It isn't usually a good practice to expose endpoints that reflect metrics/status/etc to the Internet. Currently both staging and production allow this to work. I don't think this is something that should be allowed. We define the target readiness endpoint via our chef configuration:
- https://gitlab.com/gitlab-com/gl-infra/chef-repo/-/blob/a7d15934ddf3e6951a93dc2ea215528b9cf5f676/roles/gprd-base-fe-web-pages.json#L22
- https://gitlab.com/gitlab-com/gl-infra/chef-repo/-/blob/a7d15934ddf3e6951a93dc2ea215528b9cf5f676/roles/gstg-base-fe-web-pages.json#L12
Which means anything to something such as:
Return the actual status of the service itself. While relatively harmless, should the Pages team add something fun/new/exciting to that configurable endpoint, we risk exposing information that shouldn't be.
Consider an ACL rule that block external traffic to this endpoint. Alternatively, GitLab Pages should be updated to restrict who has access to the status_uri
.
Fun Fact: In both omnibus
and our helm chart, we configure status_uri
which sets the configuration item pages-status
on the Pages service.