Basic Github Information
Structure de base
La structure de base de l'environnement github d'une grande entreprise consiste à posséder une entreprise qui détient 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 aucune entreprise.
Du point de vue de l'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 au niveau de l'entreprise, de l'organisation et du dépôt.
De plus, un utilisateur peut faire partie de différentes équipes avec différents rôles au niveau de l'entreprise, de l'organisation ou du dépôt.
Et enfin, les dépôts peuvent avoir des mécanismes de protection spéciaux.
Privilèges
Rôles au niveau de l'entreprise
Propriétaire de l'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, ils ne peuvent pas accéder aux paramètres ou au contenu de l'organisation à moins qu'ils ne soient nommés propriétaire de l'organisation ou qu'ils aient un accès direct à un dépôt appartenant à l'organisation.
Membres de l'entreprise : Les membres des organisations détenues par votre entreprise sont également automatiquement membres de l'entreprise.
Rôles au sein de l'organisation
Au sein d'une organisation, les utilisateurs peuvent avoir différents rôles :
Propriétaires de l'organisation : Les propriétaires de l'organisation ont un accès administratif complet à votre organisation. Ce rôle devrait être limité, mais pas à moins de deux personnes, dans votre organisation.
Membres de l'organisation : Le rôle par défaut, non administratif pour les personnes dans une organisation est celui de 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 de l'organisation peuvent attribuer à n'importe quelle équipe au sein d'une organisation. Lorsqu'il est appliqué, il donne à chaque membre de l'équipe les permissions de 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 de l'organisation.
Si votre organisation dispose d'une équipe de sécurité, vous pouvez utiliser le rôle de gestionnaire de sécurité pour donner aux membres de l'équipe le moins d'accès nécessaire à l'organisation.
Gestionnaires d'applications Github : Pour permettre à des utilisateurs supplémentaires de gérer les applications Github détenues par une organisation, un propriétaire peut leur accorder des permissions de gestionnaire d'applications Github.
Collaborateurs extérieurs : Un collaborateur extérieur est une personne qui a accès à un ou plusieurs dépôts de l'organisation mais qui 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
Privilèges des membres
Dans https://github.com/organizations/<org_name>/settings/member_privileges vous pouvez voir les permissions que les utilisateurs auront simplement en faisant 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 la création de forks de dépôts est possible.
Si c'est possible d'inviter des collaborateurs extérieurs.
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-codeurs qui souhaitent voir ou discuter de votre projet.
Triage : Recommandé pour les contributeurs qui doivent gérer proactivement les problèmes et les pull requests sans accès en écriture.
Écriture : Recommandé pour les contributeurs qui poussent activement sur votre projet.
Maintenance : Recommandé pour les gestionnaires de projet qui doivent gérer le dépôt sans accès aux actions sensibles ou destructrices.
Admin : Recommandé pour les personnes qui ont besoin d'un accès complet au projet, y compris les 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
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 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 propose 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 potentiellement une 2FA).
Clés SSH
Vous pouvez configurer votre compte avec une ou plusieurs clés publiques permettant à la clé privée correspondante d'effectuer des actions en votre nom. 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 est possible que vous soyez découvert pour avoir envoyé des commits sans signature. En savoir plus sur le mode vigilant ici.
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. 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
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 pouvez trouver sur certaines plateformes.
Vous pouvez créer vos propres applications Oauth sur https://github.com/settings/developers
Vous pouvez voir toutes les applications Oauth qui ont accès à votre compte sur https://github.com/settings/applications
Vous pouvez voir les scopes que les applications Oauth peuvent demander sur https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps
Vous pouvez voir l'accès des applications tierces dans une organisation sur 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 authentifié de GitHub sur l'ensemble de GitHub (par exemple, lors de la fourniture de notifications à l'utilisateur) et avec un accès uniquement aux scopes spécifiés.
Une application OAuth peut être utilisée comme fournisseur d'identité en activant un "Login with GitHub" pour l'utilisateur authentifié.
Ne créez pas une application OAuth si vous souhaitez que votre application agisse sur un seul dépôt. Avec le scope
repo
, les applications OAuth peuvent agir sur _tous_** les dépôts de l'utilisateur authentifié**.Ne créez pas une application OAuth pour agir en tant qu'application pour votre équipe ou entreprise. Les applications OAuth s'authentifient en tant que seul utilisateur, donc si une personne crée une application OAuth pour qu'une entreprise l'utilise, et qu'ensuite elle quitte l'entreprise, personne d'autre n'aura accès à celle-ci.
Plus d'informations ici.
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 sur https://github.com/settings/apps
Vous pouvez voir toutes les applications Github qui ont accès à votre compte sur https://github.com/settings/apps/authorizations
Voici les points de terminaison de l'API pour les applications Github https://docs.github.com/en/rest/overview/endpoints-available-for-github-app. Selon les permissions de l'application, elle pourra accéder à certains d'entre eux
Vous pouvez voir les applications installées dans une organisation sur 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 user-to-server). Pour sécuriser davantage les jetons d'accès user-to-server, 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 user-to-server."
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 faire.
N'utilisez pas une application GitHub si vous avez juste besoin d'un service "Login with GitHub". Mais une application GitHub peut utiliser un flux d'identification d'utilisateur pour connecter les utilisateurs et faire d'autres choses.
Ne créez pas une application GitHub si vous voulez uniquement agir en tant qu'utilisateur GitHub et faire tout ce que l'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 le scope
workflow
. L'utilisateur doit avoir des permissions d'administrateur ou d'écriture sur le dépôt qui contient le fichier de workflow. Pour plus d'informations, voir "Comprendre les scopes pour les applications OAuth."Plus d'informations ici.
Actions Github
Ceci n'est pas une méthode d'authentification sur 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. Habituellement, 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 de n'autoriser que certaines actions.
Il est également possible de configurer qui a besoin d'une approbation pour exécuter une Action Github et les permissions du GITHUB_TOKEN d'une Action Github lorsqu'elle est exécutée.
Git Secrets
Les Actions Github ont généralement besoin de certains secrets pour interagir avec github ou des applications tierces. Pour éviter de les mettre en 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 suit :
Exemple d'utilisation de Bash
Les secrets ne peuvent être accédés que depuis les Actions Github 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 pourront seulement les modifier.
Par conséquent, la seule manière de voler les secrets github est de pouvoir accéder à la machine qui exécute l'Action Github (dans ce scénario, vous aurez accès uniquement aux secrets déclarés pour l'Action).
Environnements Git
Github permet de créer des environnements où vous pouvez sauvegarder des secrets. Ensuite, vous pouvez donner à l'action github l'accès aux secrets à l'intérieur de l'environnement avec quelque chose comme :
Last updated