From 5de06a7cef7ebfe3a9c31beab96a59ff174a1f64 Mon Sep 17 00:00:00 2001 From: "Carrie Warner (Mattermost)" <74422101+cwarnermm@users.noreply.github.com> Date: Wed, 31 Jul 2024 11:40:51 -0400 Subject: [PATCH] Removed BYOK & Workspace Usage (#7308) --- source/about/cloud-subscriptions.rst | 2 +- source/guides/cloud-workspace-management.rst | 6 +- source/manage/cloud-byok.rst | 110 ------------------- source/manage/workspace-usage.rst | 11 -- 4 files changed, 2 insertions(+), 127 deletions(-) delete mode 100644 source/manage/cloud-byok.rst delete mode 100644 source/manage/workspace-usage.rst diff --git a/source/about/cloud-subscriptions.rst b/source/about/cloud-subscriptions.rst index 941237fc944..985d7f01e87 100644 --- a/source/about/cloud-subscriptions.rst +++ b/source/about/cloud-subscriptions.rst @@ -98,7 +98,7 @@ Whether customer data should be stored in Mattermost Cloud depends heavily on th Are S3-managed keys used for server-side encryption? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Yes, with Mattermost Cloud Dedicated. You can also bring your own keys for database and Amazon S3. +Yes, with Mattermost Cloud Dedicated. Are you SOC2 Type 2 certified? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/source/guides/cloud-workspace-management.rst b/source/guides/cloud-workspace-management.rst index 23d1222cbcb..2445ff865b7 100644 --- a/source/guides/cloud-workspace-management.rst +++ b/source/guides/cloud-workspace-management.rst @@ -12,14 +12,10 @@ This section of the guide is for system admins of Mattermost Cloud deployments. :hidden: :titlesonly: - Workspace usage Workspace migration Cloud data residency Cloud IP Filtering - Cloud Bring Your Own Key (BYOK) -* :doc:`Workspace usage ` - Keep your workspace active. * :doc:`Workspace migration ` - Migrate your workspace using the mmctl tool. * :doc:`Cloud data residency ` - Find information about your data in the Cloud. -* :doc:`Cloud IP Filtering ` - Restrict access to your Mattermost Cloud workspace to a specific IP address range. -* :doc:`Cloud Bring Your Own Key (BYOK) ` - Learn how to manage data encryption processes within a Mattermost Cloud Enterprise Dedicated deployment. \ No newline at end of file +* :doc:`Cloud IP Filtering ` - Restrict access to your Mattermost Cloud workspace to a specific IP address range. \ No newline at end of file diff --git a/source/manage/cloud-byok.rst b/source/manage/cloud-byok.rst deleted file mode 100644 index ac5ddfac7b2..00000000000 --- a/source/manage/cloud-byok.rst +++ /dev/null @@ -1,110 +0,0 @@ -Cloud Dedicated Bring Your Own Key -=================================== - -.. include:: ../_static/badges/ent-cloud-dedicated.rst - :start-after: :nosearch: - -Bring Your Own Key (BYOK) provides Enterprise Cloud customers with autonomy over their encryption key life cycle. BYOK supports encryption at rest with custom KMS keys that the enterprise provides and maintains. - -BYOK requires a subscription to Mattermost Cloud Enterprise Dedicated, which offers enhanced data security and compliance by ensuring that enterprises have full control over their data encryption processes. - -In Mattermost Cloud Enterprise Dedicated, you can use KMS keys in 2 ways: - -- One KMS key for all services; or, -- Per-service KMS keys (EBS, RDS, S3) - - Keys do not need to be unique to each service. - - All services must be encrypted at rest. - - Selective enablement of this feature can be supported. - - In cases where a global database is needed, we recommend providing 2 KMS keys (1 per region). - -Why use BYOC? --------------- - -Consider using BYOC with :doc:`Mattermost Cloud Dedicated ` if you have specific business needs or project requirements. There are a few major reasons to use BYOC: - -- **Compliance**: If you have strict regulatory requirements or special compliance requirements, BYOC may will be the best option for you. -- **Network auditing**: If you require the visibility of all traffic within any VPC you operate in, or need frequent auditing capabilities, BYOC is potentially a good fit. -- **Fine-grained network control**: BYOC only requires specific network access (non-internet accessible) for Mattermost (for example, service management or troubleshooting) to deploy and manage the Mattermost instance, otherwise allowing you to customize your network to meet any internal requirements or requirements of your customers. -- **Cost optimization**: Depending on your cloud provider, with BYOC you can use cost savings plans, committed use discounts, or other strategies to save on compute and storage infrastructure costs related to the Mattermost instance. - -Who is eligible for BYOC? -------------------------- - -To be eligible for BYOC, you must: - -- Use Amazon Web Service (AWS) or Azure -- Have a committed deal with Mattermost -- Have at least Mattermost Enterprise Support - -Standard BYOC architecture --------------------------- - -The standard BYOC deployment requires the organization to create a Virtual Private Cloud (BYOC VPC) dedicated to Mattermost-managed instances within a cloud region they want to operate in. Mattermost accesses this VPC through VPC PrivateLink for inbound and outbound traffic or VPC peering in order to manage the Mattermost instance. Organizations can integrate with their services using standard VPC peering techniques. - -.. image:: ../images/mattermost-cloud-dedicated-byok-architecture.png - :alt: An architecture diagram showing the components of the Mattermost Cloud Dedicated Bring Your Own Key solution. - -Configure BYOK ---------------- - -1. Enterprise customer provides their AWS KMS ARN to the Mattermost Infrastructure SRE team. -2. Enterprise customer adds the following blocks to their KMS Policy for the AWS KMS ARN provided: - -.. code-block:: JSON - - { - "Sid": "Allow use of the key", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam:::user/mattermost-cloud--provisioning-" - }, - "Action": [ - "kms:Encrypt", - "kms:Decrypt", - "kms:ReEncrypt*", - "kms:GenerateDataKey*", - "kms:DescribeKey" - ], - "Resource": "" - }, - { - "Sid": "Allow use of the key role nodes", - "Effect": "Allow", - "Principal": { - "AWS": "arn:aws:iam:::role/nodes.-kops.k8s.local" - }, - "Action": [ - "kms:Encrypt", - "kms:Decrypt", - "kms:ReEncrypt*", - "kms:GenerateDataKey*", - "kms:DescribeKey" - ], - "Resource": "" - }, - -3. The Mattermost Infrastructure SRE team updates the kops cluster and S3, RDS resources after the KMS policy is updated on the customer's end. - -Alternatively, the Enterprise customer can provide an external key (non-KMS) to the Mattermost Infrastructure SRE team that Mattermost maintains on behalf of the customer. -This path offers less control to customers but simplifies the setup process. - -Requirements -~~~~~~~~~~~~~ - -- Customers must own their AWS Account. (In the alternative path mentioned above this is delegated to Mattermost.) -- Customers oversee the maintenance life cycle of their custom KMS key. -- A valid AWS KMS ARN for encrypting storage and databases should be provided to the Infrastructure SRE team. -- The customer should incorporate the provided policy blocks from the Infrastructure SRE team into their KMS key policy. - -Considerations -~~~~~~~~~~~~~~~ - -- Changing the AWS KMS key in the database necessitates downtime due to AWS Aurora's encryption `limitations. `_ -- Proper communication is essential for setting expectations and scheduling changes. - -Conclusion ------------ - -If you are a large enterprise with compliance requirements, or are working in highly-regulated industries, using Mattermost Cloud Dedicated with BYOK ensures full data control. - -For any further assistance or queries, talk to a `Mattermost Expert `_ diff --git a/source/manage/workspace-usage.rst b/source/manage/workspace-usage.rst deleted file mode 100644 index d1830326376..00000000000 --- a/source/manage/workspace-usage.rst +++ /dev/null @@ -1,11 +0,0 @@ -Workspace usage -=============== - -.. include:: ../_static/badges/allplans-cloud.rst - :start-after: :nosearch: - -Your Mattermost Cloud workspace is considered "Active" when you're using it. If you stop using the workspace, have no activated users, have no user activity, or don't log in for 14 days, your workspace is moved to a "Hibernation" state. - -You can still access your workspace via its URL and all your data is still available. - -If your workspace isn't accessed or used for 60 days, it will be deleted. This deletion includes any data on the workspace. The URL that you chose for your workspace will become available again after a period of time.