GitLab sign-up and visibility restrictions
Locking down who can join and what anonymous users see: disabling self-registration, Hard email confirmation, allowed domains, Private defaults and restricting public visibility.
GitLab security hardening
Hardening a self-managed GitLab instance and its CI/CD: sign-up and visibility settings, SSH keys, outbound requests, secrets, environments and runner isolation.
GitLab SSH key restrictions
Setting allowed SSH key types and minimum lengths on self-managed GitLab: ED25519 first, forbidding DSA and the RSA and ECDSA minimums FIPS mode requires.
Restricting GitLab outbound requests and webhook targets
Preventing webhooks and integrations from reaching internal services: local network request settings, allowlists for specific hosts, DNS rebinding protection and system hook TLS.
Configuring GitLab rate limits
Turning on every GitLab rate limit setting as the hardening guide advises, why the defaults suit most instances and exempting service users from Notes and Users API limits.
Protecting secrets in GitLab CI/CD variables
Masked, hidden and protected variables, moving the most sensitive secrets to Vault or a cloud secrets manager, and using CI/CD inputs instead of pipeline variables for parameters.
GitLab protected environments for deployment control
Restricting who can deploy to production with protected environments, and pairing them with protected branches and runners for regulated releases.
GitLab Admin Mode and administrator access
Requiring re-authentication for administrative actions with Admin Mode, enforcing 2FA for administrators, custom admin roles and keeping the number of full administrators small.
GitLab push rules and deploy keys
Using push rules to reject unverified committers and secret files, replacing public deploy keys with project deploy keys and auditing keys that tie to blocked users.
GitLab pipeline integrity: image digests and pinned dependencies
Hardening pipelines against supply chain tampering: SHA digests for images, lock files, verified tool versions and vendoring remote includes, as GitLab's pipeline security guidance advises.
Isolating GitLab runners and privileged jobs
Containing Docker-in-Docker and other privileged jobs: ephemeral VMs, protected-branch-only runners, pull policies for mixed-trust fleets and keeping the shell executor for trusted builds.
