doc/security/dedicated_for_government_secure_config_guide.md
{{< details >}}
{{< /details >}}
FedRAMP requires Cloud Service Providers to create, maintain, and publish a secure configuration guide. The mandate includes both required and recommended criteria. Use this page to harden your Dedicated for Government instance and align with the latest FedRAMP guidance.
Required criteria:
Recommended criteria:
GitLab has an expansive set of configuration guidance available for US federal agencies and organizations serving the public sector. With transparency as a core value, the GitLab documentation already addresses the required elements of the secure configuration guide in detail.
GitLab Dedicated for Government is a single-tenant SaaS solution purpose-built for government agencies. It holds a FedRAMP Moderate Authority to Operate (ATO), runs on AWS GovCloud, and provides full infrastructure-level isolation. Each customer environment lives in a dedicated AWS account, separated from other tenants.
The architecture has two distinct administrative layers:
Infrastructure management layer : Managed by GitLab.
Application administration layer : Controlled by customer administrators.
Before reviewing the configuration settings in this guide, review the shared responsibility model for GitLab Dedicated for Government. The shared responsibility model is the foundation for understanding what hardening must be applied by federal agency administrators.
This section covers the full lifecycle of top-level administrator accounts, from secure setup and day-to-day operation to safe decommission.
FedRAMP requirement: Explain how to securely access, configure, operate, and decommission top-level administrative accounts that control enterprise access to the entire cloud service offering.
When you purchase a GitLab Dedicated for Government instance, the GitLab Dedicated team provisions your initial top-level administrator account. Dedicated engineers then assist you with configuring an integration with an identity management solution. Once configured, you have full control over administering access to your instance.
GitLab Dedicated for Government supports SAML and OpenID Connect (OIDC) for single sign-on, so you can route administrative authentication through your existing government identity infrastructure. You are responsible for integrating an identity provider to meet all relevant PIV/CAC requirements for FedRAMP.
For the full access lifecycle, see:
Administrators can add and remove other administrators as required. GitLab recommends either creating dedicated administrator accounts or turning on Admin mode, a built-in security control that requires administrators to explicitly elevate their session before accessing the Admin area. Either approach ensures that privileged accounts are used only for their corresponding privileged functions.
Once your identity platform is integrated, the top-level administrator can provision users to build out the initial user base. Apply the principle of least privilege for all user accounts. Once projects are established, access can be assigned to specific users through the following roles at the project level:
GitLab also supports the following user types for unique use cases:
GitLab supports custom roles for unique permission requirements. For more information, see project permissions and group permissions.
Once sufficient user structure is established with administrators provisioned in your identity platform, treat the top-level administrator account as a break-glass account, with all other administrative activities occurring through your standard identity provider.
FedRAMP requirement: Provide explanations of security-related settings that can be operated only by top-level administrative accounts and their security implications.
This section enumerates configuration settings specifically available to Dedicated for Government and point customers to the broad documentation already available for administering GitLab.
GitLab Dedicated for Government allows for specific infrastructure-level security and architecture configurations to be requested by top-level customer administrators, triggered through requests to the GitLab Support team.
These configurations include:
FedRAMP recommendation: Provide explanations of security-related settings that can be operated only by privileged accounts and their security implications.
Security settings available only to top-level administrators have direct implications for the security posture of your entire instance.
FedRAMP requirement: Provide explanations of security-related settings that can be operated only by top-level administrative accounts and their security implications.
GitLab Dedicated for Government supports specific infrastructure-level security and architecture configurations that you can request through the GitLab Support team.
These configurations include:
Privileged accounts below the top-level administrator have access to settings that can significantly affect the security of your instance and its data.
FedRAMP recommendation: Provide explanations of security-related settings that can be operated only by privileged accounts and their security implications.
The top-level administrator and administrator accounts provisioned through your identity provider are functionally equivalent. Use the top-level account for initial setup only. Use administrator accounts provisioned through your identity provider for all subsequent security settings and configurations. For all available configurations, see Administer GitLab.
Administrators have a broad suite of tools to secure the software development lifecycle (SDLC) and establish change management practices. For more information, see build and manage code with CI/CD.
Review the pipeline security documentation to understand how to design CI/CD pipelines with security in mind. The NIST 800-53 compliance guide has details on how to establish change control and secure branches. Review the available change management configurations to ensure that only approved changes are applied to your codebase.
You are responsible for establishing tools to secure your code. GitLab includes a suite of detection tools that you can incorporate into the development of your applications, including:
You can enforce specific CI jobs to ensure all code is assessed for vulnerabilities before being merged.
The following roles have privileged functions beyond standard user access:
These roles have extensive permissions documentation that requires careful review when provisioning users to projects and groups.
In the Admin area, administrators can export permissions, review user identities, administer groups, and more. Functions useful for meeting FedRAMP and NIST 800-53 requirements include:
GitLab provides instructions on how to configure SSH keys to authenticate and communicate with Git. Commits can be signed, providing additional verification for anyone with a public key. Administrators can establish minimum key technologies and key lengths.
You are responsible for ensuring that SSH keys are generated with FIPS-validated cryptographic modules.
GitLab provides instructions on how to configure and manage personal access tokens. GitLab supports fine-grained permissions, which can be used to scope tokens to only the permissions required for the applicable use case. Provision only the minimum required privileges to user and service tokens to limit the impact of a compromised token.
You are responsible for consuming your application logs. Contact the GitLab Support team to access specific logs in your tenant's S3 buckets. Underlying infrastructure logs are managed by Dedicated for Government engineers and monitored by GitLab Security.
GitLab supports sending email notifications and configuring application notification emails for your instance. DHS Binding Operational Directive 18-01 requires that Domain-based Message Authentication, Reporting and Conformance (DMARC) is configured for outgoing messages as spam protection. GitLab Dedicated for Government provides this configuration by default. You can turn off email notifications if you do not need that functionality.
Dedicated for Government customers must build and manage their own self-managed runners outside of their tenant. For configuration guidance, see configure runners. Build your runners using the provided FIPS versions to ensure compliance with FedRAMP requirements.
Runners are an extension of critical infrastructure connected to the FedRAMP boundary. Misconfigured or compromised runners can introduce supply chain risks to your CI/CD pipeline and downstream artifacts. Deploy runners in isolated, hardened environments outside of the Dedicated boundary. Manage access to runner authentication tokens securely, following zero trust principles, and rotate them regularly. Configure and monitor audit logging for runner activity.
Configuring secure defaults when accounts are first provisioned reduces the risk of misconfiguration and establishes a strong security baseline from the start.
FedRAMP recommendation: Set all settings to their recommended secure defaults for top-level administrative accounts and privileged accounts when initially provisioned.
The top-level administrator account is provisioned so you can configure a strong password on first login. You must register two-factor authentication (2FA) for the root user in accordance with FedRAMP requirements. GitLab supports a wide range of factors, including WebAuthn devices that are FIPS-compliant and phishing-resistant.
To align with zero trust security principles, you should:
Additional administrators provisioned through your integrated identity provider must meet organizational controls such as:
GitLab has published a CIS Benchmark to guide hardening decisions for administrators. Use it as a starting point to build secure projects and application resources within your instance.