# Informations de base sur Github

{{#include ../../banners/hacktricks-training.md}}

## Structure de base

La structure de base de l'environnement github d'une grande **entreprise** est de posséder une **entreprise** qui possède **plusieurs organisations** et chacune d'elles peut contenir **plusieurs dépôts** et **plusieurs équipes**. Les petites entreprises peuvent simplement **posséder une organisation et pas d'entreprises**.

Du point de vue d'un utilisateur, un **utilisateur** peut être **membre** de **différentes entreprises et organisations**. Au sein de celles-ci, l'utilisateur peut avoir **différents rôles d'entreprise, d'organisation et de dépôt**.

De plus, un utilisateur peut être **partie de différentes équipes** avec différents rôles d'entreprise, d'organisation ou de dépôt.

Et enfin, **les dépôts peuvent avoir des mécanismes de protection spéciaux**.

## Privilèges

### Rôles d'entreprise

- **Propriétaire d'entreprise** : Les personnes ayant ce rôle peuvent **gérer les administrateurs, gérer les organisations au sein de l'entreprise, gérer les paramètres de l'entreprise, appliquer des politiques à travers les organisations**. Cependant, elles **ne peuvent pas accéder aux paramètres ou au contenu de l'organisation** à moins qu'elles ne soient désignées comme propriétaires d'organisation ou qu'elles ne reçoivent un accès direct à un dépôt appartenant à l'organisation.
- **Membres d'entreprise** : Les membres des organisations appartenant à votre entreprise sont également **automatiquement membres de l'entreprise**.

### Rôles d'organisation

Dans une organisation, les utilisateurs peuvent avoir différents rôles :

- **Propriétaires d'organisation** : Les propriétaires d'organisation ont **un accès administratif complet à votre organisation**. Ce rôle doit être limité, mais à pas moins de deux personnes, dans votre organisation.
- **Membres d'organisation** : Le rôle **par défaut**, non administratif pour **les personnes dans une organisation** est le membre de l'organisation. Par défaut, les membres de l'organisation **ont un certain nombre de permissions**.
- **Gestionnaires de facturation** : Les gestionnaires de facturation sont des utilisateurs qui peuvent **gérer les paramètres de facturation de votre organisation**, tels que les informations de paiement.
- **Gestionnaires de sécurité** : C'est un rôle que les propriétaires d'organisation peuvent attribuer à n'importe quelle équipe dans une organisation. Lorsqu'il est appliqué, il donne à chaque membre de l'équipe des permissions pour **gérer les alertes de sécurité et les paramètres à travers votre organisation, ainsi que des permissions de lecture pour tous les dépôts** dans l'organisation.
- Si votre organisation a une équipe de sécurité, vous pouvez utiliser le rôle de gestionnaire de sécurité pour donner aux membres de l'équipe le minimum d'accès dont ils ont besoin à l'organisation.
- **Gestionnaires d'applications Github** : Pour permettre à des utilisateurs supplémentaires de **gérer les applications GitHub appartenant à une organisation**, un propriétaire peut leur accorder des permissions de gestionnaire d'application GitHub.
- **Collaborateurs externes** : Un collaborateur externe est une personne qui a **accès à un ou plusieurs dépôts de l'organisation mais n'est pas explicitement membre** de l'organisation.

Vous pouvez **comparer les permissions** de ces rôles dans ce tableau : [https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles](https://docs.github.com/en/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization#permissions-for-organization-roles)

### Privilèges des membres

Dans _https://github.com/organizations/\<org_name>/settings/member_privileges_, vous pouvez voir les **permissions que les utilisateurs auront juste pour faire partie de l'organisation**.

Les paramètres configurés ici indiqueront les permissions suivantes des membres de l'organisation :

- Être administrateur, rédacteur, lecteur ou sans permission sur tous les dépôts de l'organisation.
- Si les membres peuvent créer des dépôts privés, internes ou publics.
- Si le fork des dépôts est possible.
- S'il est possible d'inviter des collaborateurs externes.
- Si des sites publics ou privés peuvent être publiés.
- Les permissions que les administrateurs ont sur les dépôts.
- Si les membres peuvent créer de nouvelles équipes.

### Rôles de dépôt

Par défaut, les rôles de dépôt sont créés :

- **Lecture** : Recommandé pour **les contributeurs non-code** qui souhaitent voir ou discuter de votre projet.
- **Triage** : Recommandé pour **les contributeurs qui doivent gérer proactivement les problèmes et les demandes de tirage** sans accès en écriture.
- **Écriture** : Recommandé pour les contributeurs qui **poussent activement vers votre projet**.
- **Maintenir** : Recommandé pour **les chefs de projet qui doivent gérer le dépôt** sans accès à des actions sensibles ou destructrices.
- **Administrateur** : Recommandé pour les personnes qui ont besoin d'un **accès complet au projet**, y compris des actions sensibles et destructrices comme la gestion de la sécurité ou la suppression d'un dépôt.

Vous pouvez **comparer les permissions** de chaque rôle dans ce tableau [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization#permissions-for-each-role)

Vous pouvez également **créer vos propres rôles** dans _https://github.com/organizations/\<org_name>/settings/roles_.

### Équipes

Vous pouvez **lister les équipes créées dans une organisation** dans _https://github.com/orgs/\<org_name>/teams_. Notez que pour voir les équipes qui sont des enfants d'autres équipes, vous devez accéder à chaque équipe parente.

### Utilisateurs

Les utilisateurs d'une organisation peuvent être **listés** dans _https://github.com/orgs/\<org_name>/people_.

Dans les informations de chaque utilisateur, vous pouvez voir les **équipes dont l'utilisateur est membre**, et les **dépôts auxquels l'utilisateur a accès**.

## Authentification Github

Github offre différentes manières de s'authentifier à votre compte et d'effectuer des actions en votre nom.

### Accès Web

En accédant à **github.com**, vous pouvez vous connecter en utilisant votre **nom d'utilisateur et mot de passe** (et un **2FA potentiellement**).

### **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**. [https://github.com/settings/keys](https://github.com/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 pourrait être possible que vous **soyez découvert pour avoir envoyé des commits sans signature**. En savoir plus sur [le mode vigilant ici](https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits#about-vigilant-mode).

### **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**. Lors de la création d'un jeton d'accès personnel, l'**utilisateur** doit **spécifier** les **permissions** que le **jeton** aura. [https://github.com/settings/tokens](https://github.com/settings/tokens)

### Applications Oauth

Les applications Oauth peuvent vous demander des permissions **pour accéder à une partie de vos informations github ou pour vous usurper** afin d'effectuer certaines actions. Un exemple courant de cette fonctionnalité est le **bouton de connexion avec github** que vous pourriez trouver sur certaines plateformes.

- Vous pouvez **créer** vos propres **applications Oauth** dans [https://github.com/settings/developers](https://github.com/settings/developers)
- Vous pouvez voir toutes les **applications Oauth qui ont accès à votre compte** dans [https://github.com/settings/applications](https://github.com/settings/applications)
- Vous pouvez voir les **portées que les applications Oauth peuvent demander** dans [https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps](https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps)
- Vous pouvez voir l'accès des tiers des applications dans une **organisation** dans _https://github.com/organizations/\<org_name>/settings/oauth_application_policy_.

Quelques **recommandations de sécurité** :

- Une **application OAuth** doit toujours **agir en tant qu'utilisateur GitHub authentifié sur l'ensemble de GitHub** (par exemple, lors de la fourniture de notifications utilisateur) et avec accès uniquement aux portées spécifiées.
- Une application OAuth peut être utilisée comme fournisseur d'identité en activant un "Login with GitHub" pour l'utilisateur authentifié.
- **Ne** construisez pas une **application OAuth** si vous souhaitez que votre application agisse sur un **dépôt unique**. Avec la portée `repo`, les applications OAuth peuvent **agir sur _tous_** les dépôts de l'utilisateur authentifié.
- **Ne** construisez pas une application OAuth pour agir en tant qu'application pour votre **équipe ou entreprise**. Les applications OAuth s'authentifient en tant qu'**utilisateur unique**, donc si une personne crée une application OAuth pour une entreprise à utiliser, et qu'elle quitte ensuite l'entreprise, personne d'autre n'y aura accès.
- **Plus** ici [ici](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-oauth-apps).

### Applications Github

Les applications Github peuvent demander des permissions pour **accéder à vos informations github ou vous usurper** afin d'effectuer des actions spécifiques sur des ressources spécifiques. Dans les applications Github, vous devez spécifier les dépôts auxquels l'application aura accès.

- Pour installer une application GitHub, vous devez être un **propriétaire d'organisation ou avoir des permissions d'administrateur** dans un dépôt.
- L'application GitHub doit **se connecter à un compte personnel ou à une organisation**.
- Vous pouvez créer votre propre application Github dans [https://github.com/settings/apps](https://github.com/settings/apps)
- Vous pouvez voir toutes les **applications Github qui ont accès à votre compte** dans [https://github.com/settings/apps/authorizations](https://github.com/settings/apps/authorizations)
- Voici les **points de terminaison API pour les applications Github** [https://docs.github.com/en/rest/overview/endpoints-available-for-github-app](https://docs.github.com/en/rest/overview/endpoints-available-for-github-apps). En fonction des permissions de l'application, elle pourra accéder à certains d'entre eux.
- Vous pouvez voir les applications installées dans une **organisation** dans _https://github.com/organizations/\<org_name>/settings/installations_.

Quelques recommandations de sécurité :

- Une application GitHub doit **prendre des actions indépendamment d'un utilisateur** (à moins que l'application n'utilise un jeton [utilisateur-à-serveur](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps#user-to-server-requests)). Pour garder les jetons d'accès utilisateur-à-serveur plus sécurisés, vous pouvez utiliser des jetons d'accès qui expireront après 8 heures, et un jeton de rafraîchissement qui peut être échangé contre un nouveau jeton d'accès. Pour plus d'informations, voir "[Rafraîchir les jetons d'accès utilisateur-à-serveur](https://docs.github.com/en/apps/building-github-apps/refreshing-user-to-server-access-tokens)."
- Assurez-vous que l'application GitHub s'intègre avec **des dépôts spécifiques**.
- L'application GitHub doit **se connecter à un compte personnel ou à une organisation**.
- Ne vous attendez pas à ce que l'application GitHub sache et fasse tout ce qu'un utilisateur peut.
- **Ne pas utiliser une application GitHub si vous avez juste besoin d'un service "Login with GitHub"**. Mais une application GitHub peut utiliser un [flux d'identification utilisateur](https://docs.github.com/en/apps/building-github-apps/identifying-and-authorizing-users-for-github-apps) pour connecter les utilisateurs _et_ faire d'autres choses.
- Ne construisez pas une application GitHub si vous _voulez seulement_ agir en tant qu'utilisateur GitHub et faire tout ce que cet utilisateur peut faire.
- Si vous utilisez votre application avec GitHub Actions et souhaitez modifier des fichiers de workflow, vous devez vous authentifier au nom de l'utilisateur avec un jeton OAuth qui inclut la portée `workflow`. L'utilisateur doit avoir des permissions d'administrateur ou d'écriture sur le dépôt contenant le fichier de workflow. Pour plus d'informations, voir "[Comprendre les portées pour les applications OAuth](https://docs.github.com/en/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/#available-scopes)."
- **Plus** ici [ici](https://docs.github.com/en/developers/apps/getting-started-with-apps/about-apps#about-github-apps).

### Actions Github

Ceci **n'est pas un moyen de s'authentifier dans github**, mais une **action** Github malveillante pourrait obtenir un **accès non autorisé à github** et **selon** les **privilèges** accordés à l'Action, plusieurs **attaques différentes** pourraient être réalisées. Voir ci-dessous pour plus d'informations.

## Actions Git

Les actions Git permettent d'automatiser l'**exécution de code lorsqu'un événement se produit**. En général, le code exécuté est **d'une certaine manière lié au code du dépôt** (peut-être construire un conteneur docker ou vérifier que la PR ne contient pas de secrets).

### Configuration

Dans _https://github.com/organizations/\<org_name>/settings/actions_, il est possible de vérifier la **configuration des actions github** pour l'organisation.

Il est possible d'interdire complètement l'utilisation des actions github, **d'autoriser toutes les actions github**, ou simplement d'autoriser certaines actions.

Il est également possible de configurer **qui a besoin d'approbation pour exécuter une Action Github** et les **permissions du GITHUB_TOKEN** d'une Action Github lorsqu'elle est exécutée.

### Secrets Git

Les Actions Github ont généralement besoin d'un certain type de secrets pour interagir avec github ou des applications tierces. Pour **éviter de les mettre en texte clair** dans le dépôt, github permet de les mettre en tant que **Secrets**.

Ces secrets peuvent être configurés **pour le dépôt ou pour toute l'organisation**. Ensuite, pour que l'**Action puisse accéder au secret**, vous devez le déclarer comme :
```yaml
steps:
- name: Hello world action
with: # Set the secret as an input
super_secret:${{ secrets.SuperSecret }}
env: # Or as an environment variable
super_secret:${{ secrets.SuperSecret }}
```
#### Exemple utilisant Bash <a href="#example-using-bash" id="example-using-bash"></a>
```yaml
steps:
- shell: bash
env: SUPER_SECRET:${{ secrets.SuperSecret }}
run: |
example-command "$SUPER_SECRET"
```
> [!WARNING]
> Les secrets **ne peuvent être accédés que depuis les Github Actions** qui les ont déclarés.

> Une fois configurés dans le dépôt ou les organisations, **les utilisateurs de github ne pourront plus y accéder**, ils ne pourront que **les modifier**.

Par conséquent, la **seule façon de voler des secrets github est de pouvoir accéder à la machine qui exécute l'Action Github** (dans ce scénario, vous ne pourrez accéder qu'aux secrets déclarés pour l'Action).

### Git Environments

Github permet de créer **des environnements** où vous pouvez enregistrer **des secrets**. Ensuite, vous pouvez donner à l'action github l'accès aux secrets à l'intérieur de l'environnement avec quelque chose comme :
```yaml
jobs:
deployment:
runs-on: ubuntu-latest
environment: env_name
```
Vous pouvez configurer un environnement pour être **accessible** par **toutes les branches** (par défaut), **uniquement les branches protégées** ou **spécifier** quelles branches peuvent y accéder.\
Il peut également définir un **nombre d'examens requis** avant **d'exécuter** une **action** utilisant un **environnement** ou **attendre** un **certain temps** avant de permettre aux déploiements de se poursuivre.

### Git Action Runner

Une action Github peut être **exécutée dans l'environnement github** ou peut être exécutée dans une **infrastructure tierce** configurée par l'utilisateur.

Plusieurs organisations permettront d'exécuter des actions Github dans une **infrastructure tierce** car cela a tendance à être **moins cher**.

Vous pouvez **lister les runners auto-hébergés** d'une organisation à _https://github.com/organizations/\<org_name>/settings/actions/runners_

La façon de trouver quelles **actions Github sont exécutées dans une infrastructure non-github** est de rechercher `runs-on: self-hosted` dans la configuration yaml de l'action Github.

Il est **impossible d'exécuter une action Github d'une organisation à l'intérieur d'une boîte auto-hébergée** d'une autre organisation car **un jeton unique est généré pour le Runner** lors de sa configuration pour savoir à quelle organisation le runner appartient.

Si le **Github Runner personnalisé est configuré sur une machine à l'intérieur d'AWS ou de GCP**, par exemple, l'action **pourrait avoir accès au point de terminaison des métadonnées** et **voler le jeton du compte de service** avec lequel la machine fonctionne.

### Compromission de l'Action Git

Si toutes les actions (ou une action malveillante) sont autorisées, un utilisateur pourrait utiliser une **action Github** qui est **malveillante** et qui **compromettra** le **conteneur** où elle est exécutée.

> [!CAUTION]
> Une **action Github malveillante** exécutée pourrait être **abusée** par l'attaquant pour :
>
> - **Voler tous les secrets** auxquels l'action a accès
> - **Se déplacer latéralement** si l'action est exécutée à l'intérieur d'une **infrastructure tierce** où le jeton SA utilisé pour exécuter la machine peut être accessible (probablement via le service de métadonnées)
> - **Abuser du jeton** utilisé par le **workflow** pour **voler le code du repo** où l'action est exécutée ou **même le modifier**.

## Protections des Branches

Les protections des branches 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 certaine branche**.

Les **protections des branches d'un dépôt** peuvent être trouvées à _https://github.com/\<orgname>/\<reponame>/settings/branches_

> [!NOTE]
> Il est **impossible de définir une protection de branche au niveau de l'organisation**. Donc, toutes doivent être déclarées sur chaque dépôt.

Différentes protections peuvent être appliquées à une branche (comme à master) :

- Vous pouvez **exiger une PR avant de fusionner** (donc vous ne pouvez pas fusionner directement du code sur la branche). Si cela est sélectionné, d'autres protections peuvent être en place :
- **Exiger un nombre d'approbations**. Il est très courant d'exiger que 1 ou 2 autres personnes approuvent votre PR afin qu'un seul utilisateur ne puisse pas fusionner le code directement.
- **Rejeter les approbations lorsque de nouveaux commits sont poussés**. Sinon, un utilisateur peut approuver un code légitime et ensuite l'utilisateur pourrait ajouter du code malveillant et le fusionner.
- **Exiger des examens des Propriétaires de Code**. Au moins 1 propriétaire de code du dépôt doit approuver la PR (donc les utilisateurs "aléatoires" ne peuvent pas l'approuver)
- **Restreindre qui peut rejeter les examens des demandes de tirage.** Vous pouvez spécifier des personnes ou des équipes autorisées à rejeter les examens des demandes de tirage.
- **Autoriser des acteurs spécifiés à contourner les exigences des demandes de tirage**. Ces utilisateurs pourront contourner les restrictions précédentes.
- **Exiger que les vérifications de statut réussissent avant de fusionner.** Certaines vérifications doivent réussir avant de pouvoir fusionner le commit (comme une action github vérifiant qu'il n'y a pas de secret en clair).
- **Exiger la résolution des conversations avant de fusionner**. Tous les commentaires sur le code doivent être résolus avant que la PR puisse être fusionnée.
- **Exiger des commits signés**. Les commits doivent être signés.
- **Exiger une histoire linéaire.** Empêcher les commits de fusion d'être poussés vers les branches correspondantes.
- **Inclure les administrateurs**. Si cela n'est pas défini, les administrateurs peuvent contourner les restrictions.
- **Restreindre qui peut pousser vers les branches correspondantes**. Restreindre qui peut envoyer une PR.

> [!NOTE]
> Comme vous pouvez le voir, même si vous parvenez à obtenir des identifiants d'un utilisateur, **les dépôts peuvent être protégés vous empêchant de pousser du code sur master** par exemple pour compromettre le pipeline CI/CD.

## Références

- [https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-roles-for-an-organization)
- [https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)[https://docs.github.com/en/enterprise-server](https://docs.github.com/en/enterprise-server@3.3/admin/user-management/managing-users-in-your-enterprise/roles-in-an-enterprise)
- [https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github](https://docs.github.com/en/get-started/learning-about-github/access-permissions-on-github)
- [https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-github-user-account/managing-user-account-settings/permission-levels-for-user-owned-project-boards)
- [https://docs.github.com/en/actions/security-guides/encrypted-secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets)

{{#include ../../banners/hacktricks-training.md}}
