Basic Gitea Information
Structure de base
La structure de base de l'environnement Gitea consiste à regrouper les dépôts par organisation(s), chacune d'elles pouvant contenir plusieurs dépôts et plusieurs équipes. Cependant, notez que tout comme sur github, les utilisateurs peuvent avoir des dépôts en dehors de l'organisation.
De plus, un utilisateur peut être membre de différentes organisations. Au sein de l'organisation, l'utilisateur peut avoir différentes permissions sur chaque dépôt.
Un utilisateur peut également faire partie de différentes équipes avec des permissions différentes sur différents dépôts.
Et enfin, les dépôts peuvent avoir des mécanismes de protection spéciaux.
Permissions
Organisations
Lorsqu'une organisation est créée, une équipe appelée Owners est créée et l'utilisateur y est placé. Cette équipe donnera un accès administrateur sur l'organisation, ces permissions et le nom de l'équipe ne peuvent pas être modifiés.
Les administrateurs de l'organisation (propriétaires) peuvent sélectionner la visibilité de l'organisation :
Public
Limité (utilisateurs connectés uniquement)
Privé (membres uniquement)
Les administrateurs de l'organisation peuvent également indiquer si les administrateurs des dépôts peuvent ajouter et/ou supprimer l'accès pour les équipes. Ils peuvent également indiquer le nombre maximum de dépôts.
Lors de la création d'une nouvelle équipe, plusieurs paramètres importants sont sélectionnés :
Il est indiqué les dépôts de l'organisation auxquels les membres de l'équipe pourront accéder : dépôts spécifiques (dépôts où l'équipe est ajoutée) ou tous.
Il est également indiqué si les membres peuvent créer de nouveaux dépôts (le créateur obtiendra un accès administrateur).
Les permissions que les membres du dépôt auront :
Accès Administrateur
Accès Spécifique :
Équipes & Utilisateurs
Dans un dépôt, l'administrateur de l'organisation et les administrateurs du dépôt (si autorisés par l'organisation) peuvent gérer les rôles attribués aux collaborateurs (autres utilisateurs) et aux équipes. Il y a 3 rôles possibles :
Administrateur
Écriture
Lecture
Authentification Gitea
Accès Web
Utilisation de nom d'utilisateur + mot de passe et potentiellement (et recommandé) une 2FA.
Clés SSH
Vous pouvez configurer votre compte avec une ou plusieurs clés publiques permettant à la clé privée associée d'effectuer des actions en votre nom. http://localhost:3000/user/settings/keys
Clés GPG
Vous ne pouvez pas usurper l'identité de l'utilisateur avec ces clés mais si vous ne les utilisez pas, il est possible que vous soyez découvert pour avoir envoyé des commits sans signature.
Jetons d'accès personnel
Vous pouvez générer un jeton d'accès personnel pour donner à une application l'accès à votre compte. Un jeton d'accès personnel donne un accès complet à votre compte : http://localhost:3000/user/settings/applications
Applications Oauth
Tout comme les jetons d'accès personnel, les applications Oauth auront un accès complet à votre compte et aux endroits où votre compte a accès car, comme indiqué dans les docs, les scopes ne sont pas encore pris en charge :
Clés de déploiement
Les clés de déploiement peuvent avoir un accès en lecture seule ou en écriture au dépôt, elles peuvent donc être intéressantes pour compromettre des dépôts spécifiques.
Protections de branche
Les protections de branche sont conçues pour ne pas donner un contrôle complet d'un dépôt aux utilisateurs. Le but est de mettre en place plusieurs méthodes de protection avant de pouvoir écrire du code dans une branche.
Les protections de branche d'un dépôt se trouvent à https://localhost:3000/<orgname>/<reponame>/settings/branches
Il n'est pas possible de définir une protection de branche au niveau de l'organisation. Elles doivent donc toutes être déclarées sur chaque dépôt.
Différentes protections peuvent être appliquées à une branche (comme à master) :
Désactiver Push : Personne ne peut pousser vers cette branche
Activer Push : Toute personne ayant accès peut pousser, mais pas forcer le push.
Liste blanche de Push restreint : Seuls les utilisateurs/équipes sélectionnés peuvent pousser vers cette branche (mais pas forcer le push)
Activer la liste blanche de fusion : Seuls les utilisateurs/équipes en liste blanche peuvent fusionner les PR.
Activer les vérifications de statut : Exiger que les vérifications de statut passent avant de fusionner.
Exiger des approbations : Indiquer le nombre d'approbations requises avant qu'une PR puisse être fusionnée.
Restreindre les approbations aux utilisateurs en liste blanche : Indiquer les utilisateurs/équipes qui peuvent approuver les PR.
Bloquer la fusion en cas de révisions rejetées : Si des modifications sont demandées, elles ne peuvent pas être fusionnées (même si les autres vérifications passent)
Bloquer la fusion en cas de demandes de révision officielles : Si des demandes de révision officielles existent, elles ne peuvent pas être fusionnées
Annuler les approbations obsolètes : Lors de nouveaux commits, les anciennes approbations seront annulées.
Exiger des commits signés : Les commits doivent être signés.
Bloquer la fusion si la pull request est obsolète
Modèles de fichiers protégés/non protégés : Indiquer les modèles de fichiers à protéger/ne pas protéger contre les modifications
Comme vous pouvez le voir, même si vous avez réussi à obtenir des identifiants d'un utilisateur, les dépôts peuvent être protégés vous empêchant de pousser du code vers master par exemple pour compromettre le pipeline CI/CD.
Last updated
