Skip to content
代码片段 群组 项目
未验证 提交 58799fcc 编辑于 作者: Loryn Bortins's avatar Loryn Bortins 提交者： GitLab
浏览文件

Apply 7 suggestion(s) to 1 file(s) 


Co-authored-by: default avatarLysanne Pinto <lpinto@gitlab.com>
上级 684ee542
No related branches found
No related tags found
无相关合并请求
隐藏空白变更内容
行内 左右并排
doc/administration/dedicated/configure_instance.md
+ 60
− 30
浏览文件 @ 58799fcc
......@@ -25,40 +25,46 @@ An instance refers to a GitLab Dedicated deployment, whereas a tenant refers to
## Configuration changes
### Configuration change policy
### Configure your instance using Switchboard
Configuration changes requested with a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) are batched up and applied during your environment's weekly four-hour maintenance window.
You can use Switchboard to make limited configuration changes to your GitLab Dedicated instance.
This policy does not apply to configuration changes made by a GitLab Dedicated instance admin [using Switchboard](#configuration-changes-in-switchboard).
The following configuration settings are available in Switchboard:
To have a change considered for an upcoming weekly maintenance window, all required information
must be submitted in full two business days before the start of the window.
- [IP allowlist](#ip-allowlist)
- [SAML settings](#saml)
- [Custom certificates](#custom-certificates)
A configuration change might not be applied during an upcoming weekly maintenance window, even if
it meets the minimum lead time. If GitLab needs to perform high-priority maintenance tasks that
run beyond the maintenance window, configuration changes will be postponed to the following week.
Prerequisites:
- You must have the [Admin](#add-users-to-an-instance) role.
Changes requested with a support ticket cannot be applied outside of a weekly maintenance window unless it qualifies for
[emergency support](https://about.gitlab.com/support/#how-to-engage-emergency-support).
To make a configuration change:
### Configuration changes in Switchboard
1. Sign in to [Switchboard](https://console.gitlab-dedicated.com/).
1. At the top of the page, select **Configuration**.
1. Follow the instructions in the relevant sections below.
Switchboard empowers the user to make limited configuration changes to their GitLab Dedicated instance. As Switchboard matures further configuration changes will be made available.
For all other instance configurations, submit a support ticket according to the
[configuration change request policy](#configuration-change-request-policy).
To change or update the configuration of your GitLab Dedicated instance, use Switchboard following the instructions in the relevant section or open a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) with your request.
#### Applying configuration changes in Switchboard
You can request configuration changes for some of the options originally specified during onboarding, or for any of the following optional features.
You can apply configuration changes made in Switchboard immediately or defer them until your next scheduled weekly [maintenance window](../../administration/dedicated/create_instance.md#maintenance-window).
Configuration changes made with Switchboard can be applied immediately or deferred until your next scheduled weekly [maintenance window](../../administration/dedicated/create_instance.md#maintenance-window).
When you apply changes immediately:
When applied immediately, changes may take up to 90 minutes to be deployed to your environment. Individual changes are applied in the order they are saved, or you may choose to save several changes at once before applying them in one batch. After your change is deployed, you will receive an email notification. You might have to check your spam folder if it does not show up in your main email folder.
- Deployment can take up to 90 minutes.
- Changes are applied in the order they're saved.
- You can save multiple changes and apply them in one batch.
All users with access to view or edit your tenant in Switchboard will receive a notification for each change made. See how to [manage Switchboard notification preferences](#manage-notification-preferences).
After deployment, you'll receive an email notification. Check your spam folder if you don't see it in your main inbox.
All users with access to view or edit your tenant in Switchboard receive a notification for each change. For more information, see [Manage Switchboard notification preferences](#manage-notification-preferences).
NOTE:
You will only receive email notifications for changes made by a Switchboard tenant admin. Changes made by a GitLab Operator (e.g. a GitLab version update completed during a maintenance window) will not result in an email notification.
You will only receive email notifications for changes made by a Switchboard tenant admin. Changes made by a GitLab Operator (for example, a GitLab version update completed during a maintenance window) don't trigger email notifications.
#### View the configuration change log
### View the configuration change log
You can use the configuration change log to track the changes made to your GitLab Dedicated instance, including:
......@@ -82,6 +88,20 @@ To view the configuration change log:
1. Select your tenant.
1. At the top of the page, select **Configuration change log**.
### Configuration change request policy
This policy does not apply to configuration changes made by a GitLab Dedicated instance admin using Switchboard.
Configuration changes requested with a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650):
- Are applied during your environment's weekly four-hour maintenance window.
- Can be requested for options specified during onboarding or for optional features listed on this page.
- May be postponed to the following week if GitLab needs to perform high-priority maintenance tasks.
- Can't be applied outside the weekly maintenance window unless they qualify for [emergency support](https://about.gitlab.com/support/#how-to-engage-emergency-support).
NOTE:
Even if a change request meets the minimum lead time, it might not be applied during the upcoming maintenance window.
### Bring your own domain (BYOD)
You can add a [custom hostname](../../subscriptions/gitlab_dedicated/index.md#bring-your-own-domain) for your GitLab Dedicated instance. Optionally, you can also provide a custom hostname for the bundled container registry and KAS services.
......@@ -222,7 +242,7 @@ In some cases, the GitLab Dedicated instance can't reach an internal service you
#### Add a custom certificate with a Support Request
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).
If you are unable to use Switchboard to add a custom certificate, you can open a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) and attach your custom public certificate files to request this change..
#### Maximum number of reverse PrivateLink connections
......@@ -232,7 +252,7 @@ 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. Once the IP allowlist has been enabled, when an IP not on the allowlist tries to access your instance an `HTTP 403 Forbidden` response is returned.
IP addresses that have been added to your IP allowlist can be viewed on the Configuration page in Switchboard. You can add or remove IP addresses from your allowlist with Switchboard or a support request.
IP addresses that have been added to your IP allowlist can be viewed on the Configuration page in Switchboard. You can add or remove IP addresses from your allowlist with Switchboard.
#### Add an IP to the allowlist with Switchboard
......@@ -247,7 +267,7 @@ IP addresses that have been added to your IP allowlist can be viewed on the Conf
#### Add an IP to the allowlist with a Support Request
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). The IP addresses are then added to the IP allowlist for your instance.
If you are unable to use Switchboard to update your IP allowlist, you can open a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) and specify a comma separated list of IP addresses that can access your GitLab Dedicated instance.
#### Enable OpenID Connect for your IP allowlist
......@@ -286,14 +306,15 @@ To activate SAML for your GitLab Dedicated instance:
- SAML label
- IdP cert fingerprint
- IdP SSO target URL
1. Optional. To configure users based on SAML group membership, complete the following fields:
1. Optional. To configure users based on [SAML group membership](#saml-groups) or use [group sync](#group-sync), complete the following fields:
- SAML group attribute
- Admin groups
- Auditor groups
- External groups
- Required groups
1. Optional. To configure SAML request signing, complete the following fields:
1. Optional. To configure [SAML request signing](#request-signing), complete the following fields:
- Name identifier format
- Issuer
- Attribute statements
- Security
1. Select **Save**.
......@@ -305,9 +326,9 @@ To activate SAML for your GitLab Dedicated instance:
#### Activate SAML with a Support Request
To activate SAML for your GitLab Dedicated instance:
If you are unable to use Switchboard to activate or update SAML for your GitLab Dedicated instance, you can open a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650):
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:
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. At a minimum, GitLab needs the following information to enable SAML for your instance:
- IDP SSO Target URL
- Certificate fingerprint or certificate
- NameID format
......@@ -350,14 +371,23 @@ 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).
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.
NOTE:
Because SAML request signing requires certificate signing, you must complete these steps to use SAML with this feature enabled.
To enable SAML request signing:
1. Open a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) and indicate that you want request signing enabled.
1. GitLab will work with you on sending the Certificate Signing Request (CSR) for you to sign. Alternatively, the CSR can be signed with a public CA.
1. After the certificate is signed, you can then use the certificate and its associated private key to complete the `security` section of the [SAML configuration](#activate-saml-with-switchboard) in Switchboard.
Authentication requests from GitLab to your identity provider can now 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](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650).
To enable SAML groups, add the [required elements](../../integration/saml.md#configure-users-based-on-saml-group-membership) to your SAML configuration in [Switchboard](#activate-saml-with-switchboard) or to the SAML block you provide in a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650).
#### Group sync
......@@ -365,7 +395,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](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650).
1. Add the [required elements](../../user/group/saml_sso/group_sync.md#configure-saml-group-sync) to your SAML configuration in [Switchboard](#activate-saml-with-switchboard) or to the SAML configuration block you provide in a [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).
### Add users to an instance
......
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或