GitLab Dedicated encryption

• Tier: Ultimate
• Offering: GitLab Dedicated

GitLab Dedicated provides secure encryption capabilities to protect your data through robust security infrastructure provided by AWS. Data is encrypted both at rest and in transit.

Encrypted data at rest

GitLab Dedicated encrypts all stored data using AWS AES-256 (Advanced Encryption Standard with 256-bit keys). This encryption applies to all AWS storage services used by GitLab Dedicated.

All services use AES-256 encryption standard. In this envelope encryption system:

1. Your data is encrypted using Data Encryption Keys (DEKs).
2. The DEKs themselves are encrypted using AWS KMS keys.
3. Encrypted DEKs are stored alongside your encrypted data.
4. AWS KMS keys remain in the AWS Key Management Service and are never exposed in unencrypted form.
5. All encryption keys are protected by Hardware Security Modules (HSMs).

This envelope encryption process works by having AWS KMS derive the DEKs specifically for each encryption operation. The DEK directly encrypts your data, while the DEK itself is encrypted by the AWS KMS key, creating a secure envelope around your data.

Encryption key sources

Your AWS KMS encryption key can come from one of the following sources:

• AWS-managed keys (default): GitLab and AWS handle all aspects of key generation and management.
• Bring your own key (BYOK): You provide and control your own AWS KMS keys.

All key generation takes place in AWS KMS using dedicated hardware, ensuring high security standards for encryption across all storage services.

The following table summarizes the functional differences between these options:

AWS-managed keys

When you don't bring your own key, AWS uses AWS-managed KMS keys for encryption by default. These keys are automatically created and maintained by AWS for each service.

AWS KMS manages access to AWS-managed keys using AWS Identity and Access Management (IAM). This architecture ensures that even AWS personnel cannot access your encryption keys or decrypt your data directly, as all key operations are managed through the HSM-based security controls.

You do not have direct access to AWS-managed KMS keys. Only the specific AWS services you use with your instance can request encryption or decryption operations for resources they manage on your behalf.

Only AWS services that need access to the key (S3, EBS, RDS) can use them. AWS personnel do not have direct access to key material, as AWS KMS keys are protected by an internal HSM-based mechanism.

To learn more, see the Amazon documentation on AWS managed keys.

Bring your own key (BYOK)

With BYOK, you can encrypt your GitLab Dedicated data at rest using your own AWS KMS keys. This way, you retain control over your own AWS KMS encryption keys. You manage access policies through your AWS account.

BYOK must be enabled during instance onboarding. Once enabled, it cannot be disabled.

If you did not enable BYOK during onboarding, your data is still encrypted at rest with AWS-managed keys, but you cannot use your own keys.

Due to key rotation requirements, GitLab Dedicated only supports keys with AWS-managed key material (the AWS_KMS origin type).

In GitLab Dedicated, you can use KMS keys in two ways:

• One KMS key for all services.
• Per-service KMS keys (Backup, EBS, RDS, S3, Advanced Search).
  • Keys do not need to be unique to each service.
  • Selective enablement is not supported.

Create AWS KMS keys for BYOK

Create your KMS keys using the AWS Console.

Prerequisites:

• You must have received your GitLab AWS account ID from the GitLab Dedicated account team.
• Your GitLab Dedicated tenant instance must not yet be created.

To create AWS KMS keys for BYOK:

1. Sign in to the AWS Console and go to the KMS service.
2. Select Create key.
3. In the Configure key section:
   1. For Key type, select Symmetrical.
   2. For Key usage, select Encrypt and decrypt.
   3. Under Advanced options:
      1. For Key material origin, select KMS.
      2. For Regionality, select Multi-Region key.
4. Enter your values for key alias, description, and tags.
5. Select key administrators.
6. Optional. Allow or prevent key administrators from deleting the key.
7. On the Define key usage permissions page, under Other AWS accounts, add the GitLab AWS account.
8. Review the KMS key policy. It should look similar to the example below, populated with your account IDs and usernames.

{
    "Version": "2012-10-17",
    "Id": "byok-key-policy",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<CUSTOMER-ACCOUNT-ID>:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow access for Key Administrators",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<CUSTOMER-ACCOUNT-ID>:user/<CUSTOMER-USER>"
                ]
            },
            "Action": [
                "kms:Create*",
                "kms:Describe*",
                "kms:Enable*",
                "kms:List*",
                "kms:Put*",
                "kms:Update*",
                "kms:Revoke*",
                "kms:Disable*",
                "kms:Get*",
                "kms:Delete*",
                "kms:TagResource",
                "kms:UntagResource",
                "kms:ScheduleKeyDeletion",
                "kms:CancelKeyDeletion",
                "kms:ReplicateKey",
                "kms:UpdatePrimaryRegion"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow use of the key",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<GITLAB-ACCOUNT-ID>:root"
                ]
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        },
        {
            "Sid": "Allow attachment of persistent resources",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::<GITLAB-ACCOUNT-ID>:root"
                ]
            },
            "Action": [
                "kms:CreateGrant",
                "kms:ListGrants",
                "kms:RevokeGrant"
            ],
            "Resource": "*"
        }
    ]
}

For more information on creating and managing KMS keys, see the AWS KMS documentation.

Enable BYOK for your instance

To enable BYOK:

1. Collect the ARNs of each key you created.
2. Before your GitLab Dedicated tenant is provisioned, ensure these ARNs have been entered into in Switchboard during onboarding.
3. Make sure the AWS KMS keys are replicated to your desired primary, secondary, and backup regions specified in Switchboard during onboarding.

Encrypted data in transit

GitLab Dedicated encrypts all data moving over networks using TLS (Transport Layer Security) with strong cipher suites. This encryption applies to all network communications used by GitLab Dedicated services.

Encryption for data in transit is performed with TLS using keys generated and managed by GitLab Dedicated components, and is not covered by BYOK.

Custom TLS certificates

You can configure custom TLS certificates to use your organization's certificates for encrypted communications.

For more information on configuring custom certificates, see custom certificates.