doc-locale/fr-fr/administration/dedicated/configure_instance/network_security.md
{{< details >}}
{{< /details >}}
Utilisez ces paramètres pour contrôler la façon dont votre instance GitLab Dedicated se connecte à internet et à votre infrastructure privée. Vous pouvez configurer des domaines personnalisés, gérer les autorités de certification pour les services externes, configurer la connectivité réseau privée avec AWS PrivateLink, restreindre l'accès avec une liste d'autorisation IP et afficher les adresses IP sortantes utilisées par votre instance.
Vous pouvez configurer un domaine personnalisé pour accéder à votre instance GitLab Dedicated au lieu du domaine par défaut your-tenant.gitlab-dedicated.com.
Lorsque vous ajoutez un domaine personnalisé :
tenant.gitlab-dedicated.com ne sont plus disponibles.GitLab gère automatiquement les certificats SSL/TLS pour votre domaine personnalisé en utilisant Let's Encrypt. Let's Encrypt utilise le challenge HTTP-01 pour vérifier la propriété du domaine, ce qui nécessite :
Pour les instances configurées avec un réseau privé (tel qu'AWS PrivateLink), la résolution DNS publique garantit le bon fonctionnement de la gestion des certificats, même lorsque tous les autres accès sont limités aux réseaux privés.
GitLab Dedicated prend en charge les domaines personnalisés via deux méthodes de configuration :
Contactez votre Customer Success Manager pour déterminer quelle méthode de configuration s'applique à votre instance.
La section Custom domains affiche la configuration de domaine active pour votre instance GitLab Dedicated, notamment :
Utilisez ces informations pour :
Pour afficher les détails de votre domaine personnalisé :
{{< details >}}
{{< /details >}}
Si votre domaine personnalisé est configuré avec Cloudflare Web Application Firewall (WAF), Switchboard affiche des détails de configuration supplémentaires, notamment les serveurs de noms Cloudflare et les paramètres DNSSEC pour la conformité FedRAMP.
Les détails supplémentaires incluent :
Utilisez ces valeurs pour configurer la délégation DNS et la validation DNSSEC auprès de votre fournisseur DNS.
Avec cette configuration, votre domaine se connecte directement à votre instance GitLab en utilisant un enregistrement CNAME. Vous configurez vos propres enregistrements DNS et demandez l'activation du domaine via le support.
[!note] Votre domaine personnalisé doit être accessible depuis l'internet public pour la gestion des certificats SSL, même si vous accédez à votre instance via des réseaux privés.
Prérequis :
Pour configurer les enregistrements DNS :
Connectez-vous au site web de votre hébergeur de domaine.
Accédez aux paramètres DNS.
Ajoutez un enregistrement CNAME qui pointe votre domaine personnalisé vers votre instance GitLab Dedicated. Par exemple :
gitlab.my-company.com. CNAME my-tenant.gitlab-dedicated.com
Facultatif. Si votre domaine possède un enregistrement CAA existant, mettez-le à jour pour inclure Let's Encrypt comme autorité de certification valide. Par exemple :
gitlab.my-company.com. IN CAA 0 issue "pki.goog"
gitlab.my-company.com. IN CAA 0 issue "letsencrypt.org"
L'enregistrement CAA définit quelles autorités de certification peuvent émettre des certificats pour votre domaine.
Enregistrez vos modifications et attendez que les modifications DNS prennent effet.
Conservez vos enregistrements DNS en place tant que vous utilisez le domaine personnalisé.
Prérequis :
Pour activer votre domaine personnalisé :
gitlab.company.com.registry.company.com et kas.company.com.Avec cette configuration, votre domaine doit être délégué à GitLab à l'aide d'enregistrements NS, ce qui permet d'acheminer le trafic via Cloudflare Web Application Firewall (WAF). Cloudflare gère tous les paramètres DNS de votre domaine et fournit des fonctionnalités de sécurité améliorées.
[!note] Cette approche nécessite une coordination avec votre Customer Success Manager. La configuration est appliquée pendant la période de maintenance de votre instance.
Pour demander un domaine personnalisé :
gitlab.company.com.registry.company.com et kas.company.com.GitLab configure votre domaine dans Cloudflare et fournit :
name1.ns.cloudflare.com et name2.ns.cloudflare.com.Configurez des enregistrements NS dans votre fournisseur DNS pour déléguer votre sous-domaine à Cloudflare.
Prérequis :
Pour configurer les enregistrements DNS :
Connectez-vous au site web de votre hébergeur de domaine.
Accédez aux paramètres DNS.
Créez des enregistrements NS en utilisant les serveurs de noms fournis par GitLab. Par exemple :
gitlab.company.com. NS name1.ns.cloudflare.com.
gitlab.company.com. NS name2.ns.cloudflare.com.
Supprimez tous les enregistrements A, AAAA ou CNAME conflictuels pour le même sous-domaine.
Clients FedRAMP uniquement. Ajoutez un enregistrement DS en utilisant les valeurs fournies par GitLab :
gitlab.company.com. DS [Key Tag] [Algorithm] [Digest Type] [Digest]
Par exemple :
gitlab.company.com. DS 12345 13 2 A1B2C3D4E5F6...
Enregistrez vos modifications. Les modifications DNS peuvent prendre jusqu'à 48 heures pour prendre effet.
Vérifiez votre configuration :
# Verify nameserver delegation
dig +short NS gitlab.company.com
# Verify DNS resolution
dig gitlab.company.com
# Verify DNSSEC (if configured)
dig +dnssec gitlab.company.com
Informez GitLab via votre ticket de support que la configuration DNS est terminée.
GitLab effectue alors les opérations suivantes :
Le FQDN (Fully Qualified Domain Name) du registre de conteneurs identifie le compartiment S3 qui stocke les données du registre de conteneurs de votre instance.
Utilisez le FQDN plutôt que les adresses IP pour configurer les règles de pare-feu et les politiques réseau qui référencent l'emplacement de stockage du registre. Les adresses IP des compartiments S3 peuvent changer au fil du temps.
Pour afficher le FQDN de votre gistre de conteneurs :
GitLab Dedicated valide les certificats lors de la connexion à des services externes via HTTPS. Par défaut, GitLab Dedicated ne fait confiance qu'aux autorités de certification reconnues publiquement et rejette les connexions aux services dont les certificats proviennent d'autorités de certification non approuvées.
Si vos services externes utilisent des certificats d'une autorité de certification privée ou interne, vous devez ajouter cette autorité de certification à votre instance GitLab Dedicated.
Vous pourriez avoir besoin d'autorités de certification personnalisées pour :
Les blocs de chaîne de certificats (plusieurs certificats dans un seul bloc de texte) ne sont pas pris en charge. Si vous avez plusieurs certificats dans votre chaîne, ajoutez chaque certificat séparément.
Pour ajouter un certificat personnalisé :
-----BEGIN CERTIFICATE----- et -----END CERTIFICATE-----.Si vous ne pouvez pas utiliser Switchboard pour ajouter un certificat personnalisé, ouvrez un ticket de support et joignez chaque certificat personnalisé en tant que fichier séparé.
AWS PrivateLink permet la connectivité réseau privée entre votre infrastructure AWS et votre instance GitLab Dedicated sans acheminer le trafic via l'internet public. Tout le trafic reste dans le réseau AWS, ce qui réduit l'exposition aux menaces externes et peut aider à satisfaire aux exigences de conformité pour les réseaux privés.
GitLab Dedicated prend en charge deux types de connexions PrivateLink :
Les connexions PrivateLink doivent se trouver dans la même région AWS que votre instance GitLab Dedicated, et vous ne pouvez créer des services de point de terminaison que dans vos régions AWS principale et secondaire.
Pour plus d'informations sur AWS PrivateLink, consultez Qu'est-ce qu'AWS PrivateLink ?.
Les connexions PrivateLink entrantes permettent aux utilisateurs et aux applications de votre VPC de se connecter en privé à votre instance GitLab Dedicated.
Lorsque vous créez un service de point de terminaison, vous spécifiez les principaux IAM qui contrôlent l'accès. Seuls les principaux IAM que vous spécifiez peuvent créer des points de terminaison VPC pour se connecter à votre instance.
Le service de point de terminaison est disponible dans deux zones de disponibilité choisies lors de l'intégration ou sélectionnées aléatoirement.
Prérequis :
arn:aws:iam::AWS_ACCOUNT_ID:role/RoleNamearn:aws:iam::AWS_ACCOUNT_ID:role/somepath/AnotherRoleNamePour créer une connexion PrivateLink entrante :
Connectez-vous à Switchboard.
En haut de la page, sélectionnez Configuration.
Développez Inbound private connections.
Sélectionnez Add endpoint service. Ce bouton n'est pas disponible si toutes vos régions disponibles disposent déjà de services de point de terminaison.
Sélectionnez une région.
Ajoutez des principaux IAM pour les utilisateurs ou rôles AWS de votre organisation AWS qui établissent les points de terminaison VPC. Les principaux IAM doivent être des principaux de rôle IAM ou des principaux d'utilisateur IAM. Associez une politique avec les autorisations suivantes au rôle ou à l'utilisateur créant le point de terminaison VPC :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "GitLabDedicatedInboundPrivateLink",
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint",
"ec2:DescribeVpcEndpointServices",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcs",
"route53:AssociateVPCWithHostedZone"
],
"Resource": "*"
}
]
}
Sélectionnez Enregistrer. GitLab crée le service de point de terminaison et gère la vérification du domaine pour le DNS privé. Le nom du point de terminaison de service devient disponible sur la page Configuration.
Dans votre compte AWS, créez une interface de point de terminaison dans votre VPC.
Configurez l'interface de point de terminaison avec ces paramètres :
Utilisez l'URL d'instance fournie lors de l'intégration pour vous connecter à votre instance GitLab Dedicated depuis votre VPC.
Vous pouvez utiliser le module Terraform terraform-inbound-privatelink pour automatiser la configuration du point de terminaison VPC AWS et générer les enregistrements Route 53 requis lors du basculement DNS.
Créez une configuration DNS supplémentaire dans votre VPC pour accéder à KAS (agent GitLab pour Kubernetes) et au registre de conteneurs via votre réseau privé.
Prérequis :
Pour configurer le DNS pour KAS et le registre :
Dans votre console AWS, créez une zone hébergée privée pour gitlab-dedicated.com et associez-la au VPC qui contient votre connexion PrivateLink entrante.
Après avoir créé la zone hébergée privée, ajoutez les enregistrements DNS suivants (remplacez example par le nom de votre instance) :
Créez un enregistrement A pour votre instance GitLab Dedicated :
Configurez le domaine complet de votre instance (par exemple, example.gitlab-dedicated.com) pour qu'il résolve vers votre point de terminaison VPC en tant qu'alias.
Sélectionnez le point de terminaison VPC qui ne contient pas de référence à une zone de disponibilité.
Créez des enregistrements CNAME pour KAS et le registre afin qu'ils résolvent vers le domaine de votre instance GitLab Dedicated (example.gitlab-dedicated.com) :
kas.example.gitlab-dedicated.comregistry.example.gitlab-dedicated.comPour vérifier la connectivité, depuis une ressource de votre VPC, exécutez ces commandes :
nslookup kas.example.gitlab-dedicated.com
nslookup registry.example.gitlab-dedicated.com
nslookup example.gitlab-dedicated.com
Toutes les commandes doivent résoudre vers des adresses IP privées au sein de votre VPC.
Cette configuration utilise l'interface de point de terminaison VPC plutôt que des adresses IP spécifiques, ce qui la rend stable en cas de changement d'adresses IP.
Pour accéder à GitLab Pages via votre réseau privé, créez une configuration DNS supplémentaire dans votre VPC.
Pour configurer le DNS pour GitLab Pages :
<tenant_name>.gitlab-dedicated.site et associez-la au VPC qui contient votre connexion PrivateLink entrante.A apex pour le point de terminaison VPC.CNAME générique pour *.<tenant_name>.gitlab-dedicated.site qui pointe vers <tenant_name>.gitlab-dedicated.site.Les connexions PrivateLink sortantes permettent à votre instance GitLab Dedicated et aux runners hébergés de communiquer en privé avec les services exécutés dans votre VPC, sans exposer le trafic à l'internet public.
Utilisez les connexions PrivateLink sortantes pour envoyer des webhooks, importer ou mettre en miroir des projets et des dépôts, et donner aux runners hébergés l'accès à des gestionnaires de secrets personnalisés, des artefacts, des images de jobs et des déploiements dans votre infrastructure.
Vous pouvez créer jusqu'à 10 connexions PrivateLink sortantes par région. Pour consolider plus de 10 services backend derrière une seule connexion, vous pouvez utiliser le module Terraform terraform-outbound-proxy pour déployer un proxy inverse NGINX hautement disponible avec passage TLS, routage HTTP et transfert SMTP.
Prérequis :
[!note] Si vous définissez Acceptance required sur Oui, Switchboard ne peut pas déterminer avec précision quand le lien est accepté. Après avoir accepté manuellement le lien, le statut s'affiche comme En attente au lieu de Actif jusqu'à la prochaine maintenance planifiée. Après la maintenance, le statut du lien est actualisé et s'affiche comme connecté.
Pour ajouter une connexion PrivateLink sortante avec Switchboard :
Pour ajouter une connexion PrivateLink sortante via une demande de support :
GitLab configure votre instance pour créer les interfaces de point de terminaison nécessaires en fonction des noms de service que vous avez fournis. PrivateLink dirige les connexions sortantes correspondantes vers votre VPC.
Une zone hébergée privée (PHZ) crée des enregistrements DNS personnalisés (tels que A, CNAME ou d'autres types d'enregistrements) qui se résolvent dans le réseau de votre instance GitLab Dedicated.
Utilisez une PHZ lorsque vous souhaitez :
Les PHZ sont couramment utilisées avec le PrivateLink inverse pour créer des noms de domaine lisibles au lieu d'utiliser des noms de point de terminaison générés par AWS. Par exemple, vous pouvez utiliser alpha.beta.tenant.gitlab-dedicated.com au lieu de vpce-0987654321fedcba0-k99y1abc.vpce-svc-0a123bcd4e5f678gh.eu-west-1.vpce.amazonaws.com.
Dans certains cas, vous pouvez également utiliser des PHZ pour créer des enregistrements DNS qui résolvent vers des noms DNS accessibles publiquement. Par exemple, vous pouvez créer un nom DNS interne qui résout vers un point de terminaison public lorsque des systèmes internes ont besoin d'accéder à un service via son nom privé.
[!note] Les modifications apportées aux zones hébergées privées peuvent perturber les services qui utilisent ces enregistrements pendant jusqu'à cinq minutes.
Les enregistrements PHZ peuvent pointer vers différents types de cibles. L'approche la plus courante et recommandée consiste à pointer vers des noms DNS pour les points de terminaison AWS VPC.
Lorsque vous utilisez le domaine de votre instance GitLab Dedicated dans le cadre d'un alias avec un point de terminaison VPC, vous devez inclure au moins un sous-domaine avant le domaine principal. Par exemple :
subdomain1.<your-tenant-id>.gitlab-dedicated.com.<your-tenant-id>.gitlab-dedicated.com.Pour les domaines personnalisés, vous devez fournir un nom PHZ et une entrée PHZ au format phz-entry.phz-name.com.
Si votre enregistrement PHZ pointe vers un nom DNS qui n'est pas un point de terminaison VPC, vous devez inclure au moins deux sous-domaines avant le domaine principal. Par exemple : subdomain1.subdomain2.tenant.gitlab-dedicated.com.
Pour ajouter une zone hébergée privée :
Available ou Pending Acceptance sont affichées.Si vous ne pouvez pas utiliser Switchboard pour ajouter une zone hébergée privée, ouvrez un ticket de support et fournissez une liste de noms DNS qui doivent résoudre vers le service de point de terminaison pour la connexion PrivateLink sortante. La liste peut être mise à jour selon les besoins.
Contrôlez les adresses IP pouvant accéder à votre instance avec une liste d'autorisation IP. Lorsque vous activez la liste d'autorisation IP, les adresses IP ne figurant pas sur la liste sont bloquées et reçoivent une réponse HTTP 403 Forbidden lorsqu'elles tentent d'accéder à votre instance.
Utilisez Switchboard pour configurer et gérer votre liste d'autorisation IP, ou soumettez une demande de support si Switchboard est indisponible.
Pour ajouter des adresses IP à la liste d'autorisation :
Connectez-vous à Switchboard.
En haut de la page, sélectionnez Configuration.
Développez IP allowlist, puis sélectionnez IP allowlist pour accéder à la page de liste d'autorisation IP.
Pour activer la liste d'autorisation IP, sélectionnez les points de suspension verticaux ({{< icon name="ellipsis_v" >}}), puis sélectionnez Activé.
Effectuez l'une des opérations suivantes :
192.168.1.1).192.168.1.0/24).En haut de la page, choisissez d'appliquer les modifications immédiatement ou lors de la prochaine fenêtre de maintenance.
Connectez-vous à Switchboard.
En haut de la page, sélectionnez Configuration.
Développez IP allowlist, puis sélectionnez IP allowlist pour accéder à la page de liste d'autorisation IP.
Effectuez l'une des opérations suivantes :
En haut de la page, choisissez d'appliquer les modifications immédiatement ou lors de la prochaine fenêtre de maintenance.
Si vous ne pouvez pas utiliser Switchboard pour mettre à jour votre liste d'autorisation IP, ouvrez un ticket de support et spécifiez une liste d'adresses IP séparées par des virgules pouvant accéder à votre instance.
L'utilisation de GitLab en tant que fournisseur d'identité OpenID Connect nécessite un accès internet au point de terminaison de vérification OpenID Connect.
Pour activer l'accès au point de terminaison OpenID Connect tout en maintenant votre liste d'autorisation IP :
La configuration est appliquée lors de la prochaine fenêtre de maintenance.
Vous pouvez utiliser SCIM avec des fournisseurs d'identité externes pour provisionner et gérer automatiquement les utilisateurs. Pour utiliser SCIM, votre fournisseur d'identité doit pouvoir accéder aux points de terminaison de l'API SCIM de l'instance. Par défaut, la liste d'autorisation IP bloque les communications vers ces points de terminaison.
Pour activer SCIM tout en maintenant votre liste d'autorisation IP :
La configuration est appliquée lors de la prochaine fenêtre de maintenance.
Les adresses IP de passerelle NAT sont les adresses IP sortantes utilisées par votre instance lors de la connexion à des services externes. Ces adresses IP restent généralement stables, mais peuvent changer si GitLab reconstruit votre instance lors d'une reprise après sinistre.
Utilisez ces adresses IP pour configurer les récepteurs de webhooks et définir des listes d'autorisation pour que les services externes acceptent les connexions de votre instance.
Pour afficher les adresses IP de votre passerelle NAT :
Lorsque vous utilisez des connexions AWS PrivateLink, vous pouvez rencontrer les problèmes suivants.
Service name could not be verified {#error-service-name-could-not-be-verified}Lors de la création d'un point de terminaison VPC pour une connexion PrivateLink entrante, vous pouvez obtenir une erreur indiquant Service name could not be verified.
Ce problème survient lorsque le rôle IAM personnalisé fourni dans le ticket de support ne dispose pas des autorisations requises ou des politiques de confiance configurées dans votre compte AWS.
Pour résoudre ce problème :
Confirmez que vous pouvez endosser le rôle IAM personnalisé fourni à GitLab dans le ticket de support.
Vérifiez que le rôle personnalisé dispose d'une politique de confiance qui vous permet de l'endosser. Par exemple :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::CONSUMER_ACCOUNT_ID:user/user-name"
},
"Action": "sts:AssumeRole"
}
]
}
Vérifiez que le rôle personnalisé dispose d'une politique d'autorisation permettant les actions de point de terminaison VPC et EC2. Par exemple :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "vpce:*",
"Resource": "*"
},
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint",
"ec2:DescribeVpcEndpointServices",
"ec2:DescribeVpcEndpoints"
],
"Resource": "*"
}
]
}
En utilisant le rôle personnalisé, réessayez de créer le point de terminaison VPC dans votre console ou CLI AWS.
Si votre connexion PrivateLink sortante ne fonctionne pas, vérifiez les points suivants :