doc-locale/fr-fr/administration/settings/account_and_limit_settings.md
{{< details >}}
{{< /details >}}
Les administrateurs GitLab peuvent configurer les limites de projet et de compte sur leur instance, comme :
Vous pouvez configurer le nombre maximum par défaut de projets que les nouveaux utilisateurs peuvent créer dans leur espace de nommage personnel. Cette limite s'applique uniquement aux nouveaux comptes utilisateur créés après la modification du paramètre. Ce paramètre n'est pas rétroactif pour les utilisateurs existants, mais vous pouvez modifier séparément les limites de projets pour les utilisateurs existants.
Pour configurer le nombre maximum de projets dans les espaces de nommage personnels pour les nouveaux utilisateurs :
Si vous définissez Limite de projets par défaut à 0, les utilisateurs ne sont pas autorisés à créer des projets dans leur espace de nommage personnel. Cependant, des projets peuvent toujours être créés dans un groupe.
Vous pouvez modifier un utilisateur spécifique et changer le nombre maximum de projets que cet utilisateur peut créer dans son espace de nommage personnel :
La taille de fichier maximale pour les pièces jointes dans les commentaires et réponses GitLab est de 100 Mo. Pour modifier la taille maximale des pièces jointes :
Si vous choisissez une taille supérieure à la valeur configurée pour le serveur web, vous pourriez recevoir des erreurs. Pour plus d'informations, consultez la section de dépannage.
Pour les limites de taille de dépôt sur GitLab.com, consultez les paramètres du compte et des limites.
Vous pouvez modifier la taille maximale de poussée pour votre instance :
Pour les limites de taille de poussée sur GitLab.com, consultez les paramètres du compte et des limites.
[!note] Lorsque vous ajoutez des fichiers à un dépôt via l'interface web, la taille maximale des pièces jointes est le facteur limitant. Cela se produit car le serveur web doit recevoir le fichier avant que GitLab puisse générer le commit. Utilisez Git LFS pour ajouter des fichiers volumineux à un dépôt. Ce paramètre ne s'applique pas lors de la poussée d'objets Git LFS.
{{< details >}}
{{< /details >}}
Les dépôts de votre instance GitLab peuvent croître rapidement, en particulier si vous utilisez LFS. Leur taille peut croître de façon exponentielle, consommant rapidement le stockage disponible. Pour éviter que cela se produise, vous pouvez définir une limite stricte pour la taille de vos dépôts. Cette limite peut être définie globalement, par groupe ou par projet, les limites par projet ayant la priorité la plus élevée.
La limite de taille du dépôt s'applique aux projets privés et publics. Elle inclut les fichiers du dépôt et les objets Git LFS (même lorsqu'ils sont stockés dans un stockage d'objets externe), mais n'inclut pas :
Il existe de nombreux cas d'utilisation où vous pourriez définir une limite pour la taille du dépôt. Par exemple, considérez le flux de travail suivant :
Sur GitLab Self-Managed et GitLab Dedicated, seul un administrateur GitLab peut définir ces limites. Définir la limite à 0 signifie qu'il n'y a aucune restriction. Pour les limites de taille de dépôt sur GitLab.com, consultez les paramètres du compte et des limites.
Ces paramètres se trouvent dans :
La première poussée d'un nouveau projet, y compris les objets LFS, est vérifiée quant à sa taille. Si la somme de leurs tailles dépasse la taille maximale autorisée du dépôt, la poussée est rejetée.
Pour déterminer si un projet approche de sa limite de taille de dépôt configurée :
Vous pouvez également utiliser l'API Projects pour récupérer les statistiques du dépôt.
Pour réduire la taille du dépôt, consultez les méthodes pour réduire la taille du dépôt.
Vous pouvez modifier la durée pendant laquelle les utilisateurs peuvent rester connectés sans activité.
[!warning] Définir Session duration (minutes) à
0provoque une défaillance de votre instance GitLab. Pour plus d'informations, consultez le ticket 19469.
[!note] Pour GitLab Dedicated, soumettez un ticket de support pour demander un redémarrage de votre instance.
Si l'option Se souvenir de moi est activée, les sessions des utilisateurs peuvent rester actives indéfiniment.
Pour plus de détails, consultez les cookies utilisés pour la connexion.
{{< history >}}
session_expire_from_init. Activé par défaut.session_expire_from_init supprimé.{{< /history >}}
Par défaut, les sessions expirent après un délai défini suivant l'inactivité de la session. À la place, vous pouvez configurer les sessions pour qu'elles expirent après un délai défini suivant la création de la session.
Lorsque la durée de session est atteinte, la session se termine et l'utilisateur est déconnecté même si :
Après la fin d'une session, une fenêtre invite l'utilisateur à se reconnecter.
{{< history >}}
{{< /history >}}
Les utilisateurs peuvent cocher la case Se souvenir de moi lors de la connexion. Leur session reste active indéfiniment lorsqu'elle est accédée depuis ce navigateur spécifique. Désactivez ce paramètre pour faire expirer les sessions à des fins de sécurité ou de conformité. La désactivation de ce paramètre garantit que les sessions des utilisateurs expirent après le nombre de minutes d'inactivité défini lorsque vous personnalisez la durée de votre session.
{{< details >}}
{{< /details >}}
<!-- The history line is too old, but must remain until `feature_flags/development/two_factor_for_cli.yml` is removed -->{{< history >}}
two_factor_for_cli. Désactivé par défaut. Ce feature flag affecte également l'authentification à deux facteurs pour les opérations Git via SSH.{{< /history >}}
[!flag] La disponibilité de cette fonctionnalité est contrôlée par un feature flag. Pour plus d'informations, consultez l'historique. Cette fonctionnalité n'est pas prête pour une utilisation en production.
Les administrateurs GitLab peuvent choisir de personnaliser la durée de session (en minutes) pour les opérations Git lorsque l'authentification à deux facteurs est activée. La valeur par défaut est 15 et peut être définie sur une valeur comprise entre 1 et 10080.
Pour définir une limite sur la durée de validité de ces sessions :
{{< details >}}
{{< /details >}}
{{< history >}}
allow_top_level_group_owners_to_create_service_accounts pour GitLab Self-Managed. Désactivé par défaut.allow_top_level_group_owners_to_create_service_accounts supprimé.{{< /history >}}
Par défaut, seuls les administrateurs peuvent créer des comptes de service. Vous pouvez configurer GitLab pour permettre également aux propriétaires de groupe principal de créer des comptes de service.
Prérequis :
Pour autoriser les propriétaires de groupe principal à créer des comptes de service :
{{< details >}}
{{< /details >}}
{{< history >}}
{{< /history >}}
Prérequis :
Vous pouvez exiger que tous les nouveaux jetons d'accès aient une date d'expiration. Ce paramètre est activé par défaut et s'applique à :
Pour les jetons d'accès personnels des comptes de service, utilisez le paramètre service_access_tokens_expiration_enforced dans l'API des paramètres d'application.
Pour exiger des dates d'expiration pour les nouveaux jetons d'accès :
Lorsque vous exigez des dates d'expiration pour les nouveaux jetons d'accès :
{{< details >}}
{{< /details >}}
Par défaut, GitLab supprime les jetons d'accès de groupe et de projet ainsi que leur famille de jetons 30 jours après que le dernier jeton actif de la famille de jetons devient inactif. Cette suppression retire tous les jetons de la famille de jetons, l'utilisateur bot associé, et déplace toutes les contributions du bot vers un utilisateur fantôme.
Prérequis :
Pour modifier la période de conservation des jetons inactifs :
Vous pouvez également utiliser l'API des paramètres d'application pour modifier l'attribut inactive_resource_access_tokens_delete_after_days.
Vous pouvez spécifier un préfixe pour les jetons d'accès personnels. Les avantages de l'utilisation d'un préfixe personnalisé incluent :
Le préfixe par défaut pour les jetons d'accès personnels est glpat-, mais les administrateurs peuvent le modifier. Les jetons d'accès au projet et les jetons d'accès de groupe héritent également de ce préfixe.
[!warning] Par défaut, la détection des secrets côté client, la protection contre la poussée de secrets et la détection des secrets dans les pipelines ne détectent pas les jetons ayant un préfixe personnalisé. Cela pourrait entraîner une augmentation des faux négatifs. Cependant, vous pouvez personnaliser la détection des secrets dans les pipelines pour détecter ces jetons.
Pour modifier le préfixe global par défaut :
Vous pouvez également configurer le préfixe en utilisant l'API des paramètres.
{{< history >}}
custom_prefix_for_all_token_types. Désactivé par défaut.{{< /history >}}
[!flag] La disponibilité de cette fonctionnalité est contrôlée par un feature flag. Pour plus d'informations, consultez l'historique. Cette fonctionnalité est disponible pour les tests, mais n'est pas prête pour une utilisation en production.
Vous pouvez définir un préfixe personnalisé qui est ajouté au début de tous les jetons générés sur votre instance. Les avantages de l'utilisation d'un préfixe personnalisé incluent :
[!warning] Par défaut, la détection des secrets côté client, la protection contre la poussée de secrets et la détection des secrets dans les pipelines ne détectent pas les jetons ayant un préfixe personnalisé. Cela pourrait entraîner une augmentation des faux négatifs. Cependant, vous pouvez personnaliser la détection des secrets dans les pipelines pour détecter ces jetons.
Les préfixes de jetons personnalisés s'appliquent uniquement aux jetons suivants :
Prérequis :
Pour définir un préfixe de jeton personnalisé :
{{< details >}}
{{< /details >}}
{{< history >}}
buffered_token_expiration_limit. Désactivé par défaut.{{< /history >}}
[!flag] La disponibilité de la limite de durée de vie maximale autorisée étendue est contrôlée par un feature flag. Pour plus d'informations, consultez l'historique. Le feature flag n'est pas disponible sur GitLab Dedicated.
Les utilisateurs peuvent optionnellement spécifier une durée de vie maximale en jours pour les jetons d'accès ; cela inclut les jetons d'accès personnels, de groupe et de projet. Cette durée de vie n'est pas une obligation et peut être définie sur n'importe quelle valeur supérieure à 0 et inférieure ou égale à :
buffered_token_expiration_limit. Cette limite étendue n'est pas disponible sur GitLab Dedicated.Si ce paramètre est laissé vide, la durée de vie maximale autorisée par défaut des jetons d'accès est :
buffered_token_expiration_limit. Cette limite étendue n'est pas disponible sur GitLab Dedicated.Les jetons d'accès sont les seuls jetons nécessaires pour l'accès programmatique à GitLab. Cependant, les organisations ayant des exigences de sécurité peuvent souhaiter renforcer la protection en exigeant la rotation régulière de ces jetons.
Seul un administrateur GitLab peut définir une durée de vie. La laisser vide signifie qu'il n'y a aucune restriction.
Pour définir une durée de vie sur la validité des jetons d'accès :
Après la définition d'une durée de vie pour les jetons d'accès, GitLab :
{{< details >}}
{{< /details >}}
Les utilisateurs peuvent optionnellement spécifier une durée de vie pour les clés SSH. Cette durée de vie n'est pas une obligation et peut être définie sur n'importe quel nombre de jours arbitraire.
Les clés SSH sont des identifiants utilisateur pour accéder à GitLab. Cependant, les organisations ayant des exigences de sécurité peuvent souhaiter renforcer la protection en exigeant la rotation régulière de ces clés.
Seul un administrateur GitLab peut définir une durée de vie. La laisser vide signifie qu'il n'y a aucune restriction.
Pour définir une durée de vie sur la validité des clés SSH :
Après la définition d'une durée de vie pour les clés SSH, GitLab :
buffered_token_expiration_limit. Cette limite étendue n'est pas disponible sur GitLab Dedicated.[!note] Lorsque la clé SSH d'un utilisateur devient invalide, il peut supprimer et rajouter la même clé.
{{< details >}}
{{< /details >}}
Prérequis :
Le paramètre Applications OAuth de l'utilisateur contrôle si les utilisateurs peuvent enregistrer des applications pour utiliser GitLab comme fournisseur OAuth. Ce paramètre affecte les applications OAuth appartenant aux utilisateurs, mais n'affecte pas les applications OAuth appartenant aux groupes.
Pour activer ou désactiver le paramètre Applications OAuth de l'utilisateur :
{{< details >}}
{{< /details >}}
Pour maintenir l'intégrité des informations utilisateur dans les événements d'audit, les administrateurs GitLab peuvent empêcher les utilisateurs de modifier leur nom de profil.
Pour ce faire :
Lorsque cette option est sélectionnée, les administrateurs GitLab peuvent toujours mettre à jour les noms d'utilisateur dans la zone Admin ou via l'API.
{{< details >}}
{{< /details >}}
{{< history >}}
ui_for_organizations. Désactivé par défaut.{{< /history >}}
[!flag] Sur GitLab Self-Managed, cette fonctionnalité n'est pas disponible par défaut. Pour la rendre disponible, un administrateur peut activer le feature flag nommé
ui_for_organizations. Sur GitLab.com et GitLab Dedicated, cette fonctionnalité n'est pas disponible. Cette fonctionnalité n'est pas prête pour une utilisation en production.
Par défaut, les utilisateurs peuvent créer des organisations. Les administrateurs GitLab peuvent empêcher les utilisateurs de créer des organisations.
Par défaut, les nouveaux utilisateurs peuvent créer des groupes principaux. Les administrateurs GitLab peuvent empêcher les nouveaux utilisateurs de créer des groupes principaux :
[!note] Ce paramètre s'applique uniquement aux utilisateurs ajoutés après la désactivation du paramètre. Les utilisateurs existants peuvent toujours créer des groupes principaux.
{{< history >}}
{{< /history >}}
Par défaut, les utilisateurs ayant le rôle Invité peuvent créer des projets et des groupes. Les administrateurs GitLab peuvent empêcher ce comportement :
{{< details >}}
{{< /details >}}
{{< history >}}
disallow_private_profiles. Désactivé par défaut.disallow_private_profiles supprimé.{{< /history >}}
Par défaut, les utilisateurs peuvent rendre leurs profils privés. Les administrateurs GitLab peuvent désactiver ce paramètre pour exiger que tous les profils utilisateur soient publics. Ce paramètre n'affecte pas les utilisateurs internes (parfois appelés « bots »).
Pour empêcher les utilisateurs de rendre leurs profils privés :
Lorsque vous désactivez ce paramètre :
Lorsque vous réactivez ce paramètre, la visibilité de profil définie précédemment par l'utilisateur est sélectionnée.
Par défaut, les utilisateurs nouvellement créés ont un profil public. Les administrateurs GitLab peuvent définir les nouveaux utilisateurs avec un profil privé par défaut :
[!note] Si Autoriser les utilisateurs à rendre leurs profils privés est désactivé, ce paramètre est également désactivé.
{{< details >}}
{{< /details >}}
{{< history >}}
deleting_account_disabled_for_users. Activé par défaut.{{< /history >}}
Par défaut, les utilisateurs peuvent supprimer leurs propres comptes. Les administrateurs GitLab peuvent empêcher les utilisateurs de supprimer leurs propres comptes :
{{< details >}}
{{< /details >}}
Lorsque vous joignez un fichier à un commentaire ou une réponse dans GitLab, la taille maximale des pièces jointes est probablement supérieure à la valeur autorisée par le serveur web.
Pour augmenter la taille maximale des pièces jointes à 200 Mo dans une installation de paquet Linux :
Ajoutez cette ligne à /etc/gitlab/gitlab.rb :
nginx['client_max_body_size'] = "200m"
Augmentez la taille maximale des pièces jointes.
Si vous recevez des erreurs de poussée intermittentes dans votre journal des exceptions Rails, comme ceci :
Your push to this repository cannot be completed because this repository has exceeded the allocated storage for your project.
Les tâches de maintenance peuvent entraîner la croissance de la taille de votre dépôt. Pour résoudre ce problème, l'une ou l'autre de ces options aide à court ou moyen terme :