Basic Gitea Information
Structure de base
La structure de base de l'environnement Gitea consiste à regrouper des dépôts par organisation(s), chacune 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 autorisations sur chaque dépôt.
Un utilisateur peut également faire partie de différentes équipes avec des autorisations différentes sur différents dépôts.
Enfin, les dépôts peuvent avoir des mécanismes de protection spéciaux.
Autorisations
Organisations
Lorsqu'une organisation est créée, une équipe appelée Propriétaires est créée et l'utilisateur y est placé. Cette équipe donnera un accès administratif sur l'organisation, ces autorisations et le nom de l'équipe ne peuvent pas être modifiés.
Les administrateurs de l'org (propriétaires) peuvent sélectionner la visibilité de l'organisation :
Publique
Limitée (utilisateurs connectés uniquement)
Privée (membres uniquement)
Les administrateurs de l'org peuvent également indiquer si les administrateurs de dépôt peuvent ajouter et/ou supprimer l'accès pour les équipes. Ils peuvent également indiquer le nombre maximal 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'org 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 administratif).
Les autorisations 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'org et les administrateurs de dépôt (si autorisé par l'org) peuvent gérer les rôles attribués aux collaborateurs (autres utilisateurs) et aux équipes. Il existe 3 rôles possibles :
Administrateur
Écriture
Lecture
Authentification Gitea
Accès Web
En utilisant nom d'utilisateur + mot de passe et éventuellement (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 vous faire passer pour l'utilisateur avec ces clés mais si vous ne les utilisez pas, il pourrait être possible que vous soyez découvert pour l'envoi de commits sans signature.
Jetons d'accès personnels
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 personnels, les applications Oauth auront un accès complet à votre compte et aux endroits où votre compte a accès car, comme indiqué dans la documentation, les étendues ne sont pas encore prises 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, il peut donc être intéressant de 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. L'objectif 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 peuvent être trouvées dans https://localhost:3000/<nomorg>/<nomrepo>/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 la poussée : Personne ne peut pousser sur cette branche
Activer la poussée : Toute personne ayant accès peut pousser, mais pas de force push.
Liste blanche de poussée restreinte : Seuls les utilisateurs/équipes sélectionnés peuvent pousser sur cette branche (mais pas de force push)
Activer la liste blanche de fusion : Seuls les utilisateurs/équipes en liste blanche peuvent fusionner les PR.
Activer les vérifications d'état : Exiger que les vérifications d'état passent avant la fusion.
Exiger des approbations : Indiquer le nombre d'approbations requises avant qu'un PR puisse être fusionné.
Restreindre les approbations aux personnes en liste blanche : Indiquer les utilisateurs/équipes pouvant approuver les PR.
Bloquer la fusion sur les avis rejetés : Si des modifications sont demandées, elles ne peuvent pas être fusionnées (même si les autres vérifications passent)
Bloquer la fusion sur les demandes d'avis officiels : Si des demandes d'avis officiels sont en attente, elles ne peuvent pas être fusionnées
Rejeter les approbations obsolètes : Avec de nouveaux commits, les anciennes approbations seront rejetées.
Exiger des commits signés : Les commits doivent être signés.
Bloquer la fusion si la demande de tirage est obsolète
Modèles de fichiers protégés/non protégés : Indiquer les modèles de fichiers à protéger/non protéger contre les modifications
Comme vous pouvez le voir, même si vous parvenez à obtenir les identifiants d'un utilisateur, les dépôts peuvent être protégés pour vous empêcher de pousser du code sur master par exemple pour compromettre le pipeline CI/CD.
Dernière mise à jour
