Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/doc/administration/dedicated/index.md
diff options
context:
space:
mode:
Diffstat (limited to 'doc/administration/dedicated/index.md')
-rw-r--r--doc/administration/dedicated/index.md101
1 files changed, 82 insertions, 19 deletions
diff --git a/doc/administration/dedicated/index.md b/doc/administration/dedicated/index.md
index db30684ab1c..b995c837136 100644
--- a/doc/administration/dedicated/index.md
+++ b/doc/administration/dedicated/index.md
@@ -35,14 +35,41 @@ To request the creation of a new GitLab Dedicated environment for your organizat
### Maintenance window
-When onboarding, you must also specify your preference for the weekly four-hour time slot that GitLab uses to perform maintenance and upgrade operations on the tenant instance.
+When onboarding, you must also specify your preference for the weekly four-hour time slot that GitLab uses to perform routine maintenance and upgrade operations on all tenant instances.
-- APAC (outside working hours): Wednesday 1pm-5pm UTC
-- EU (outside working hours): Tuesday 1am-5am UTC
-- AMER (outside working hours): Tuesday 7am-11am UTC
+Available scheduled maintenance windows, performed outside standard working hours:
-NOTE:
-Some downtime may be incurred during this window. This downtime is not counting towards [the system SLA](https://about.gitlab.com/handbook/engineering/infrastructure/team/gitlab-dedicated/slas/).
+- APAC: Wednesday 1 AM - 5 AM UTC
+- EU: Tuesday 1 AM - 5 AM UTC
+- AMER Option 1: Tuesday 7 AM - 11 AM UTC
+- AMER Option 2: Sunday 9 PM - Monday 1 AM UTC
+
+Consider the following notes:
+
+- In case of a performance degradation or downtime during the scheduled maintenance window,
+ the impact to [the system SLA](https://about.gitlab.com/handbook/engineering/infrastructure/team/gitlab-dedicated/slas/) is not counted.
+- The weekly scheduled maintenance window can be postponed into another window within the same week.
+ This option needs to be agreed with the assigned Customer Success Manager at least one week in advance.
+- The scheduled weekly maintenance window is different from
+ [emergency maintenance](#emergency-maintenance).
+
+#### Emergency maintenance
+
+In an event of a platform outage, degradation or a security event requiring urgent action,
+emergency maintenance will be carried out per
+[the emergency change processes](https://about.gitlab.com/handbook/engineering/infrastructure/emergency-change-processes/).
+
+The emergency maintenance is initiated urgently when urgent actions need to be executed by GitLab
+on a Dedicated tenant instance.
+Communication with the customer will be provided on best effort basis prior to commencing the
+maintenance, and full communication will follow after the immediate action is carried out.
+
+For example, when a critical security process is initiated to address an S1 vulnerability in GitLab,
+emergency maintenance is carried out to upgrade GitLab to the non-vulnerable version and that
+can occur outside of a scheduled maintenance window.
+Postponing emergency maintenance is not possible, because the same process must be applied to all
+existing Dedicated customers, and the primary concern is to ensure safety and availability of
+Dedicated tenant instances.
## Configuration changes
@@ -59,10 +86,12 @@ If you want your GitLab data to be encrypted at rest, the KMS keys used must be
If you use a key per service, all services must be encrypted at rest. Selective enablement of this feature is not supported.
-The keys provided have to reside in the same primary and secondary region specified during [onboarding](#onboarding).
+The keys provided have to reside in the same primary, secondary and backup region specified during [onboarding](#onboarding).
For instructions on how to create and manage KMS keys, visit [Managing keys](https://docs.aws.amazon.com/kms/latest/developerguide/getting-started.html) in the AWS KMS documentation.
+GitLab Dedicated supports only AWS managed KMS keys with KMS [as key material](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-origin).
+
To create a KMS key using the AWS Console:
1. In `Configure key`, select:
@@ -156,13 +185,15 @@ The last page asks you to confirm the KMS key policy. It should look similar to
}
```
+Make sure the AWS KMS keys are replicated to your desired primary, secondary and backup region specified during [onboarding](#onboarding).
+
### Inbound Private Link
[AWS Private Link](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) allows users and applications in your VPC on AWS to securely connect to the GitLab Dedicated endpoint without network traffic going over the public internet.
To enable the Inbound Private Link:
-1. In the body of your [support ticket](#configuration-changes), include the IAM Principal for the AWS user or role in your own AWS Organization that's establishing the VPC endpoint in your AWS account. GitLab Dedicated uses this IAM Principal for access-control. This IAM principal is the only one able to set up an endpoint to the service.
+1. In the body of your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650), include the IAM Principal for the AWS user or role in your own AWS Organization that's establishing the VPC endpoint in your AWS account. GitLab Dedicated uses this IAM Principal for access-control. This IAM principal is the only one able to set up an endpoint to the service.
1. After your IAM Principal has been allowlisted, GitLab [creates the Endpoint Service](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html) and communicates the `Service Endpoint Name` on the support ticket. The service name is generated by AWS upon creation of the service endpoint.
- GitLab handles the domain verification for the Private DNS name, so that DNS resolution of the tenant instance domain name in your VPC resolves to the PrivateLink endpoint.
- GitLab makes the Endpoint Service available in the Availability Zones you specified during the initial onboarding. If you did not specify any Availability Zones, GitLab randomly selects the Availability Zones IDs.
@@ -179,8 +210,8 @@ Outbound Private Links allow the GitLab Dedicated instance to securely communica
To enable an Outbound Private Link:
-1. In your [support ticket](#configuration-changes), GitLab provides you with an IAM role ARN that connects to your endpoint service. You can then add this ARN to the allowlist on your side to restrict connections to your endpoint service.
-1. [Create the Endpoint service](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html) through which your internal service is available to GitLab Dedicated. Provide the associated `Service Endpoint Name` on the [support ticket](#configuration-changes).
+1. In your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650), GitLab provides you with an IAM role ARN that connects to your endpoint service. You can then add this ARN to the allowlist on your side to restrict connections to your endpoint service.
+1. [Create the Endpoint service](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html) through which your internal service is available to GitLab Dedicated. Provide the associated `Service Endpoint Name` on the [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650).
1. When creating the Endpoint service, you must provide GitLab with a [verified Private DNS Name](https://docs.aws.amazon.com/vpc/latest/privatelink/manage-dns-names.html#verify-domain-ownership) for your service. Optionally, if you would like GitLab Dedicated to reach your service via other aliases, you have the ability to specify a list of Private Hosted Zone (PHZ) entries. With this option, GitLab sets up a Private Hosted Zone with DNS names aliased to the verified Private DNS name. To enable this functionality, you must provide GitLab a list of PHZ entries on your support ticket. After the PHZ is created in the tenant environment, DNS resolution of any of the provided records correctly resolves to the PrivateLink endpoint.
1. GitLab then configures the tenant instance to create the necessary Endpoint Interfaces based on the service names you provided. Any outbound calls made from the tenant GitLab instance are directed through the PrivateLink into your VPC.
@@ -188,7 +219,7 @@ To enable an Outbound Private Link:
In some cases, the GitLab Dedicated instance can't reach an internal service you own because it exposes a certificate that can't be validated using a public Certification Authority (CA). In these cases, custom certificates are required.
-To request that GitLab add custom certificates when communicating with your services over PrivateLink, attach the custom public certificate files to your [support ticket](#configuration-changes).
+To request that GitLab add custom certificates when communicating with your services over PrivateLink, attach the custom public certificate files to your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650).
#### Maximum number of reverse PrivateLink connections
@@ -198,22 +229,54 @@ GitLab Dedicated limits the number of reverse PrivateLink connections to 10.
GitLab Dedicated allows you to control which IP addresses can access your instance through an IP allowlist.
-Specify a comma separated list of IP addresses that can access your GitLab Dedicated instance in your [support ticket](#configuration-changes). After the configuration has been applied, when an IP not on the allowlist tries to access your instance, the connection is refused.
+Specify a comma separated list of IP addresses that can access your GitLab Dedicated instance in your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650). After the configuration has been applied, when an IP not on the allowlist tries to access your instance, the connection is refused.
### SAML
+NOTE:
+GitLab Dedicated supports a limited number of SAML parameters. Parameters not shown in the configuration below are unavailable for GitLab Dedicated tenant instances.
+
Prerequisites:
- You must configure the identity provider before sending the required data to GitLab.
To activate SAML for your GitLab Dedicated instance:
-1. To make the necessary changes, include the desired [SAML configuration block](../../integration/saml.md#configure-saml-support-in-gitlab) for your GitLab application in your [support ticket](#configuration-changes). At a minimum, GitLab needs the following information to enable SAML for your instance:
- - Assertion consumer service URL
+1. To make the necessary changes, include the desired [SAML configuration block](../../integration/saml.md#configure-saml-support-in-gitlab) for your GitLab application in your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650). At a minimum, GitLab needs the following information to enable SAML for your instance:
+ - IDP SSO Target URL
- Certificate fingerprint or certificate
- NameID format
- SSO login button description
+ ```json
+ "saml": {
+ "attribute_statements": {
+ //optional
+ },
+ "enabled": true,
+ "groups_attribute": "",
+ "admin_groups": [
+ // optional
+ ],
+ "idp_cert_fingerprint": "43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8",
+ "idp_sso_target_url": "https://login.example.com/idp",
+ "label": "IDP Name",
+ "name_identifier_format": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
+ "security": {
+ // optional
+ },
+ "auditor_groups": [
+ // optional
+ ],
+ "external_groups": [
+ // optional
+ ],
+ "required_groups": [
+ // optional
+ ],
+ }
+ ```
+
1. After GitLab deploys the SAML configuration to your instance, you are notified on your support ticket.
1. To verify the SAML configuration is successful:
- Check that the SSO login button description is displayed on your instance's login page.
@@ -222,14 +285,14 @@ To activate SAML for your GitLab Dedicated instance:
#### Request signing
If [SAML request signing](../../integration/saml.md#sign-saml-authentication-requests-optional) is desired, a certificate must be obtained. This certificate can be self-signed which has the advantage of not having to prove ownership of an arbitrary Common Name (CN) to a public Certificate Authority (CA)).
-
-To enable SAML request signing, indicate on your SAML [support ticket](#configuration-changes) that you want request signing enabled. GitLab works with you on sending the Certificate Signing Request (CSR) for you to sign. Alternatively, the CSR can be signed with a public CA. After the certificate is signed, GitLab adds the certificate and its associated private key to the `security` section of the SAML configuration. Authentication requests from GitLab to your identity provider can then be signed.
+If you choose to enable SAML request signing, the manual steps below will need to be completed before you are able to use SAML, since it requires certificate signing to happen.
+To enable SAML request signing, indicate on your SAML [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) that you want request signing enabled. GitLab works with you on sending the Certificate Signing Request (CSR) for you to sign. Alternatively, the CSR can be signed with a public CA. After the certificate is signed, GitLab adds the certificate and its associated private key to the `security` section of the SAML configuration. Authentication requests from GitLab to your identity provider can then be signed.
#### SAML groups
With SAML groups you can configure GitLab users based on SAML group membership.
-To enable SAML groups, add the [required elements](../../integration/saml.md#configure-users-based-on-saml-group-membership) to the SAML configuration block you provide in your [support ticket](#configuration-changes).
+To enable SAML groups, add the [required elements](../../integration/saml.md#configure-users-based-on-saml-group-membership) to the SAML configuration block you provide in your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650).
#### Group sync
@@ -237,7 +300,7 @@ With [group sync](../../user/group/saml_sso/group_sync.md), you can sync users a
To enable group sync:
-1. Add the [required elements](../../user/group/saml_sso/group_sync.md#configure-saml-group-sync) to the SAML configuration block you provide in your [support ticket](#configuration-changes).
+1. Add the [required elements](../../user/group/saml_sso/group_sync.md#configure-saml-group-sync) to the SAML configuration block you provide in your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650).
1. Configure the [Group Links](../../user/group/saml_sso/group_sync.md#configure-saml-group-links).
### Access to application logs
@@ -246,5 +309,5 @@ GitLab [application logs](../../administration/logs/index.md) are delivered to a
To gain read only access to this bucket:
-1. Open a [support ticket](#configuration-changes) with the title "Customer Log Access". In the body of the ticket, include a list of IAM Principal ARNs (users or roles) that are fetching the logs from S3.
+1. Open a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) with the title "Customer Log Access". In the body of the ticket, include a list of IAM Principal ARNs (users or roles) that are fetching the logs from S3.
1. GitLab then informs you of the name of the S3 bucket. Your nominated users/roles can then able to list and get all objects in the S3 bucket.
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-15 14:38:56 +0300