Name: Tremplin Numérique
Price range: $$$

L’un des défis de tout flux de travail DevOps est la gestion des secrets, des mots de passe et des jetons qui doivent rester confidentiels pour des raisons de sécurité. Cela est particulièrement vrai pour les référentiels open source, où le code est généralement public. GitHub Secrets aide à gérer ce problème lorsque vous travaillez avec des scripts GitHub Actions.

Sommaire

Que sont les secrets GitHub ?

GitHub Secrets est essentiellement un coffre-fort dans lequel vous pouvez stocker des clés privées, auquel les scripts GitHub Actions peuvent accéder par leur nom, un peu comme les variables d’environnement. Cela résout le problème de le conserver en clair dans la base de code, ce qui est un énorme problème de sécurité, même pour les référentiels privés, et impossible pour les référentiels publics sans se faire pirater immédiatement.

Ceci est utile dans de nombreux cas où le code peut être public, mais le script Actions doit s’authentifier auprès d’un service tiers. Par exemple, si vous hébergez des fichiers binaires sur des compartiments Amazon S3, vous devrez donner au script le jeton d’accès pour écrire sur le stockage AWS. Bien sûr, vous ne voulez pas donner à quiconque consulte le référentiel l’autorisation d’écraser le contenu du compartiment. L’utilisation d’un secret limite l’accès et protège également la clé d’une fuite accidentelle.

Les secrets de référentiel s’appliquent à un référentiel unique. Vous devrez les définir à partir du panneau des paramètres du référentiel, auquel vous pourrez ensuite accéder comme des variables d’environnement dans les builds GitHub Actions.
Les secrets des organisations GitHub s’appliqueront à tous les référentiels de cette organisation, offrant un moyen simple de gérer les clés de manière centralisée. Ils sont définis dans les paramètres de l’organisation.
Les secrets d’environnement s’appliquent à des environnements GitHub spécifiques dans le dépôt, comme develop et production. Cela fournit un moyen simple de remplacer les secrets du référentiel/de l’organisation pour différentes versions, comme le déploiement dans un environnement de test par rapport à un environnement de production.

Actuellement, il n’existe aucun moyen de définir des secrets spécifiques à l’utilisateur. Si vous voulez cette fonctionnalité, envisagez de créer une organisation personnelle.

Vous pouvez stocker jusqu’à 1 000 secrets d’organisation, 100 secrets de référentiel et 100 secrets d’environnement. Les secrets sont également limités à 64 Ko, bien qu’il existe des solutions à cette limitation. Vous pouvez également stocker des données binaires sous forme de chaînes encodées en Base64.

Il est toujours possible de les fuir du script Actions si, par exemple, vous les avez imprimés sur la console avec une commande comme echo. Vous voudrez vous assurer qu’aucun des scripts dans lesquels vous fournissez les secrets ne les relit à l’utilisateur ou ne les génère dans des fichiers journaux. Heureusement, GitHub empêche le secret d’être transmis à certaines commandes de journalisation, notamment echo.

Utilisation des secrets GitHub

Pour définir un secret à l’échelle du référentiel, vous devez vous diriger vers le panneau des paramètres du référentiel et cliquer sur Secrets > Actions. Vous pouvez également définir des secrets pour GitHub Codespaces et Dependabot, si vous les utilisez.

Vous pouvez définir un nom de variable et coller le contenu secret. Une fois que vous quittez cette fenêtre, vous ne pourrez plus voir la clé, mais vous pouvez la modifier et coller une nouvelle clé. C’est généralement ainsi que la plupart des magasins secrets devraient fonctionner et c’est une bonne fonctionnalité de sécurité, mais ne vous attendez pas à pouvoir revoir cette clé.

La convention de dénomination pour les noms secrets est en majuscules avec des traits de soulignement, autrement connus sous le nom de « cas de serpent hurlant », mais cela n’est appliqué par rien.

Ensuite, dans votre script Actions, vous pouvez le référencer en l’échappant en tant que variable YAML, comme ceci :

${{ secrets.SECRET_NAME }}

Notez que les « secrets ». Le contexte doit être inclus avant le nom secret. Vous n’avez pas non plus besoin de faire quoi que ce soit de spécial pour référencer les secrets d’organisation par rapport à ceux à référentiel unique.

Cette valeur peut être transmise aux commandes, mais vous pouvez également l’utiliser pour définir des variables d’environnement pour un processus. C’est généralement ainsi que la plupart des outils acceptent les secrets de toute façon, car c’est le système le plus sûr et le plus flexible.

Si un secret n’existe pas dans votre compte, GitHub utilisera une chaîne vide comme valeur.

Secrets d’organisation

La définition des secrets à l’échelle de l’organisation se fait de la même manière, mais il existe des contrôles supplémentaires sur l’accès et la distribution.

Lors de la création d’un secret d’organisation, vous pouvez choisir de l’appliquer uniquement aux référentiels publics ou privés, bien que les secrets privés pour l’organisation soient une option payante. Vous pouvez également sélectionner des référentiels individuels.

Pour créer ou modifier un secret d’organisation, vous devez disposer d’un accès « administrateur » à l’organisation elle-même. Cela peut être accordé à tous les membres en modifiant les autorisations de base, mais n’est généralement pas conseillé pour les grandes organisations.