From 1dcf1f993b771673f1db5e17cbb70424161b6592 Mon Sep 17 00:00:00 2001 From: Craig Miskell <cmiskell@gitlab.com> Date: Thu, 26 Sep 2024 16:28:47 +0000 Subject: [PATCH] docs: Clarifications regarding BYOK on Dedicated Captures a few details that had to be explained in https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/team/-/issues/6305 --- doc/administration/dedicated/create_instance.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/doc/administration/dedicated/create_instance.md b/doc/administration/dedicated/create_instance.md index ea863ba3234d8..34d1918431c30 100644 --- a/doc/administration/dedicated/create_instance.md +++ b/doc/administration/dedicated/create_instance.md @@ -37,10 +37,12 @@ complete your onboarding to create a new instance. ### Encrypted Data At Rest (BYOK) NOTE: -To enable BYOK, you must do it before onboarding. +To enable BYOK, you must do it before onboarding. If enabled, it is not possible to later disable BYOK. You can opt to encrypt your GitLab data at rest with AWS KMS keys, which must be made accessible to GitLab Dedicated infrastructure. Due to key rotation requirements, GitLab Dedicated only supports keys with AWS-managed key material (the [AWS_KMS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-origin) origin type). +Encryption for data in motion (moving over a network) is performed with TLS using keys generated and managed by GitLab Dedicated components, and is not covered by BYOK. + In GitLab Dedicated, you can use KMS keys in two ways: - One KMS key for all services -- GitLab