doc-locale/fr-fr/subscriptions/gitlab_dedicated/_index.md
{{< details >}}
{{< /details >}}
GitLab Dedicated est une solution SaaS à locataire unique qui est :
Chaque instance fournit :
Avec GitLab Dedicated, vous pouvez :
GitLab Dedicated attribue à chaque locataire un ensemble d'URL par défaut en fonction du type d'environnement. Remplacez tenant_name par le nom de votre locataire.
| Composant | Production | Pré-production |
|---|---|---|
| Instance GitLab | tenant_name.gitlab-dedicated.com | tenant_name.gitlab-dedicated.systems |
| GitLab Pages | tenant_name.gitlab-dedicated.site | tenant_name.gitlab-dedicated-pages.systems |
| Switchboard (console de gestion) | console.gitlab-dedicated.com | console.gitlab-dedicated.systems |
Vous pouvez remplacer l'URL par défaut de l'instance GitLab par un domaine personnalisé. Les domaines personnalisés ne sont pas pris en charge pour GitLab Pages, et les URL Switchboard ne peuvent pas être personnalisées.
Cette section répertorie les fonctionnalités clés disponibles pour GitLab Dedicated.
GitLab Dedicated fournit les fonctionnalités de sécurité suivantes pour protéger vos données et contrôler l'accès à votre instance.
GitLab Dedicated prend en charge les fournisseurs SAML et OpenID Connect (OIDC) pour l'authentification unique (SSO).
Vous pouvez configurer l'authentification unique (SSO) à l'aide des fournisseurs pris en charge pour l'authentification. Votre instance agit en tant que fournisseur de services, et vous fournissez la configuration nécessaire pour que GitLab communique avec vos fournisseurs d'identité (IdPs).
Deux options de connectivité sont disponibles :
Pour les connexions privées aux ressources internes utilisant des certificats non publics, vous pouvez également spécifier des certificats de confiance.
Si vos webhooks et intégrations doivent se connecter à des services non accessibles depuis l'internet public, vous pouvez utiliser AWS PrivateLink pour la connectivité privée. Étant donné que GitLab Dedicated est un service SaaS, il ne peut pas se connecter directement aux adresses IP locales de votre réseau.
Pour configurer la connectivité privée pour vos services internes :
Si vous avez besoin de vous connecter à plus de 10 endpoints, vous pouvez utiliser le module Terraform terraform-outbound-proxy pour déployer un proxy inverse dans votre VPC. Cette approche achemine plusieurs services via moins de connexions PrivateLink.
Les données sont chiffrées au repos et en transit à l'aide des dernières normes de chiffrement.
Vous pouvez également utiliser votre propre clé de chiffrement AWS Key Management Service (KMS) pour les données au repos. Cette option vous donne un contrôle total sur les données que vous stockez dans GitLab.
Pour plus d'informations, consultez Chiffrement de GitLab Dedicated.
Par défaut, Amazon Simple Email Service (Amazon SES) est utilisé pour envoyer des e-mails de façon sécurisée. Vous pouvez également configurer votre propre service de messagerie via SMTP.
{{< details >}}
{{< /details >}}
Cloudflare est mis en œuvre en tant que pare-feu d'application web (WAF) pour la protection contre les attaques par déni de service distribué (DDoS) et les fonctionnalités de sécurité associées. La mise en œuvre et la configuration du WAF sont gérées par l'équipe SRE de GitLab. L'accès direct à la configuration ou aux journaux du WAF n'est pas disponible.
GitLab Dedicated respecte diverses réglementations, certifications et cadres de conformité pour garantir la sécurité et la fiabilité de vos données.
Vous pouvez consulter les détails de conformité et de certification, et télécharger les artefacts de conformité depuis le GitLab Dedicated Trust Center.
GitLab Dedicated met en œuvre des contrôles d'accès stricts pour protéger votre environnement :
Dans les situations d'urgence, les ingénieurs GitLab doivent :
Toutes les actions dans les comptes Hub et locataires sont enregistrées dans CloudTrail.
Dans les comptes locataires, GitLab Dedicated utilise :
Vous pouvez accéder aux journaux d'application à des fins d'audit et d'observabilité. Ces journaux fournissent des informations sur les activités système et les actions des utilisateurs, vous aidant à surveiller votre instance et à maintenir les exigences de conformité.
Par défaut, votre instance GitLab Dedicated est accessible à son URL par défaut. Vous pouvez configurer un domaine personnalisé pour utiliser votre propre nom de domaine, tel que gitlab.company.com.
Utilisez des domaines personnalisés pour :
Vous pouvez configurer des domaines personnalisés pour :
registry.company.com)kas.company.com)Pour plus d'informations, consultez les domaines personnalisés.
[!note] GitLab Pages ne prend pas en charge les domaines personnalisés. Les sites Pages sont accessibles uniquement à l'URL Pages par défaut, quelle que soit la configuration d'un domaine personnalisé pour votre instance GitLab Dedicated.
Par défaut, GitLab Dedicated active les téléchargements directs depuis S3 pour des performances optimales (proxy_download = false). Les téléchargements via proxy ne sont pas pris en charge. Les paramètres suivants ne peuvent pas être définis sur true :
proxy_download dans la configuration de stockage d'objets consolidéedependency_proxy_object_store_proxy_download dans la configuration de stockage d'objets du proxy de dépendancesLes types d'objets qui prennent en charge les téléchargements directs incluent :
Lorsque vous téléchargez l'un des types d'objets ci-dessus, votre navigateur ou client se connecte directement à Amazon S3 plutôt que de passer par l'infrastructure GitLab.
GitLab Dedicated est fourni avec le jeu de fonctionnalités Ultimate en mode self-managed, avec quelques exceptions. Pour plus d'informations, consultez Fonctionnalités non disponibles.
GitLab Dedicated utilise les fonctionnalités de recherche avancée.
Vous pouvez accéder aux fonctionnalités analytiques avancées via l'intégration ClickHouse Cloud, qui est activée par défaut pour les clients éligibles. Vous êtes éligible si :
Vous pouvez utiliser GitLab Pages sur GitLab Dedicated pour héberger votre site web statique. Pages est activé par défaut.
Votre site web utilise l'URL Pages par défaut.
[!note] Les domaines personnalisés ne sont pas pris en charge. Si vous ajoutez un domaine personnalisé tel que
gitlab.my-company.com, vous accédez quand même à votre site web à l'URL Pages par défaut.
Si vous migrez depuis GitLab Self-Managed et souhaitez conserver un domaine générique existant (par exemple, *.gitlab-pages.company.com), vous pouvez utiliser le module Terraform terraform-gitlab-pages-redirect pour émettre des redirections 301 depuis votre domaine générique existant vers votre URL Pages par défaut.
Contrôlez l'accès à votre site web avec :
Vos listes d'autorisation d'IP existantes sont appliquées à vos sites web Pages.
En cas de basculement lors d'une reprise après sinistre, votre site continue de fonctionner depuis la région secondaire.
Les runners hébergés pour GitLab Dedicated vous permettent de faire évoluer vos charges de travail CI/CD sans aucune charge de maintenance.
Comme alternative à l'utilisation des runners hébergés, vous pouvez utiliser vos propres runners pour votre instance GitLab Dedicated.
Pour utiliser des runners self-managed, installez GitLab Runner sur une infrastructure que vous possédez ou gérez.
Vous pouvez utiliser SCIM pour la gestion des utilisateurs ou GitLab en tant que fournisseur d'identité OpenID Connect tout en maintenant les restrictions IP de votre instance.
Pour utiliser ces fonctionnalités avec des listes d'autorisation d'IP :
GitLab Dedicated prend en charge les environnements de pré-production qui correspondent à la configuration des environnements de production. Vous pouvez utiliser les environnements de pré-production pour :
Les environnements de pré-production doivent être achetés en tant qu'extension à votre abonnement GitLab Dedicated, sans licences supplémentaires requises.
Les capacités suivantes sont disponibles :
Limitations :
Bien que vous puissiez modifier la plupart des paramètres via la zone d'administration, GitLab gère automatiquement certains paramètres pour garantir la stabilité et la sécurité du système.
GitLab configure les limites de débit en fonction de la taille de votre instance et les réinitialise automatiquement à ces valeurs par défaut lors des fenêtres de maintenance pour garantir des performances optimales. Ces limites empêchent tout utilisateur ou toute automatisation de dégrader les performances pour les autres utilisateurs de votre instance.
Pour plus d'informations sur le fonctionnement des limites de débit dans GitLab Dedicated, consultez les limites de débit des utilisateurs authentifiés.
GitLab configure les poids de stockage pour distribuer uniformément les nouveaux dépôts sur les nœuds Gitaly. Si vous modifiez les poids de stockage dans la zone d'administration, GitLab écrase vos modifications lors du prochain déploiement.
Cette section répertorie les fonctionnalités qui ne sont pas disponibles pour GitLab Dedicated.
| Fonctionnalité | Description | Impact |
|---|---|---|
| Authentification LDAP | Authentification à l'aide des identifiants LDAP/Active Directory d'entreprise. | Vous devez utiliser des mots de passe spécifiques à GitLab ou des jetons d'accès à la place. |
| Authentification par carte à puce | Authentification à l'aide de cartes à puce pour une sécurité renforcée. | Impossible d'utiliser l'infrastructure de carte à puce existante. |
| Authentification Kerberos | Authentification unique à l'aide du protocole Kerberos. | Vous devez vous authentifier séparément auprès de GitLab. |
| FortiAuthenticator/FortiToken 2FA | Authentification à deux facteurs à l'aide des solutions de sécurité Fortinet. | Impossible d'intégrer l'infrastructure Fortinet 2FA existante. |
| Clone Git via HTTPS avec nom d'utilisateur/mot de passe | Opérations Git utilisant l'authentification par nom d'utilisateur et mot de passe via HTTPS. | Vous devez utiliser des jetons d'accès pour les opérations Git. |
| Authentification par certificat SSH | Authentification SSH à l'aide de certificats émis par une autorité de certification (CA). | Vous devez utiliser une autre méthode d'authentification SSH, telle que les clés SSH. |
| Sigstore | Signature et vérification sans clé pour la sécurité de la chaîne d'approvisionnement logicielle. | Vous devez utiliser des méthodes de signature de code traditionnelles. |
| Remappage de port | Remapper des ports tels que SSH (22) vers différents ports entrants. | GitLab Dedicated utilise uniquement les ports de communication par défaut. |
| Fonctionnalité | Description | Impact |
|---|---|---|
| Répondre par e-mail | Répondre aux notifications et discussions GitLab par e-mail. | Vous devez utiliser l'interface web GitLab pour répondre. |
| Service Desk | Système de tickets permettant aux utilisateurs externes de créer des tickets par e-mail. | Les utilisateurs externes doivent avoir des comptes GitLab pour créer des tickets. |
| Fonctionnalité | Description | Impact |
|---|---|---|
| Certaines fonctionnalités IA de GitLab Duo | Fonctionnalités basées sur l'IA pour la détection des vulnérabilités et la productivité. | Assistance IA limitée pour les tâches de développement. |
| Fonctionnalités masquées par des feature flags désactivés | Fonctionnalités en version expérimentale et en version bêta en cours de développement. | Aucun accès aux fonctionnalités en version expérimentale ou en version bêta. |
Pour plus d'informations sur les fonctionnalités d'IA, consultez GitLab Duo.
Les feature flags sont utilisés pour prendre en charge le développement et le déploiement des nouvelles fonctionnalités, en version expérimentale et bêta. Dans GitLab Dedicated :
Lorsqu'une fonctionnalité devient généralement disponible, elle l'est dans la même version conformément au calendrier des releases pour les déploiements.
| Fonctionnalité | Description | Impact |
|---|---|---|
| Domaines personnalisés | Héberger des sites GitLab Pages sur des noms de domaine personnalisés. | Sites Pages accessibles uniquement via l'URL Pages par défaut. |
| Espaces de nommage dans le chemin URL | Organiser les sites Pages avec une structure d'URL basée sur les espaces de nommage. | Options d'organisation des URL limitées. |
Les fonctionnalités opérationnelles suivantes ne sont pas disponibles :
Les fonctionnalités suivantes nécessitent un accès direct au serveur et ne peuvent pas être configurées :
| Fonctionnalité | Description | Impact |
|---|---|---|
| Hooks Git côté serveur | Scripts personnalisés qui s'exécutent lors des événements Git (pre-receive, post-receive). | Utilisez des règles de push ou des webhooks. |
[!note] Les hooks Git côté serveur ne sont pas pris en charge pour des raisons de sécurité et de performance. À la place, utilisez des règles de push pour appliquer des politiques de dépôt ou des webhooks pour déclencher des actions externes lors d'événements Git.
GitLab Dedicated maintient un objectif de niveau de service mensuel de disponibilité à 99,9 %.
La disponibilité du niveau de service mesure le pourcentage de temps pendant lequel GitLab Dedicated est disponible au cours d'un mois calendaire. GitLab calcule la disponibilité sur la base des services principaux suivants :
| Zone de service | Fonctionnalités incluses |
|---|---|
| Interface web | Tickets GitLab, merge requests, API GitLab, opérations Git via HTTPS |
| Registre de conteneurs | Requêtes HTTPS au registre |
| Opérations Git | Opérations Git push, pull et clone via SSH |
Les éléments suivants ne sont pas inclus dans les calculs de disponibilité du niveau de service :
Pour plus d'informations sur la reprise après sinistre, y compris les objectifs de récupération, consultez la reprise après sinistre pour GitLab Dedicated.
Pour migrer vos données vers GitLab Dedicated :
Avant l'expiration de votre abonnement, vous recevez une notification indiquant que la date de fin approche.
Lorsque votre abonnement expire, vous pouvez accéder à votre instance pendant 30 jours.
Pour préserver vos données, contactez votre équipe de compte ou envoyez un e-mail au Support dans les 15 jours suivant l'expiration pour demander la conservation des données.
Durant cette période de 30 jours, vous pouvez :
Après 30 jours, si vos données ne sont pas archivées ou migrées vers une autre instance, votre instance est résiliée et tout le contenu client est supprimé. Cela inclut tous les projets, dépôts, tickets, merge requests et autres données.
Vous pouvez demander une confirmation de suppression de compte 90 jours après la résiliation de l'instance. La confirmation est fournie sous la forme d'un e-mail d'AWS indiquant que votre compte est fermé.
Pour plus d'informations sur GitLab Dedicated ou pour demander une démonstration, consultez GitLab Dedicated.
Pour plus d'informations sur la configuration de votre instance GitLab Dedicated, consultez Créer votre instance GitLab Dedicated.