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 raisons de sécurité. Cela est particulièrement vrai pour les référentiels open source, où le code est généralement public. Les secrets GitHub aident à gérer ce problème lorsque vous travaillez avec des scripts GitHub Actions.
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 dépôts privés, et impossible pour les dépôts 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 entendu, vous ne souhaitez pas autoriser quiconque consulte le référentiel à é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 du référentiel s'appliquent à un seul référentiel. 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 à partir des paramètres de l'organisation.
- Les secrets d'environnement s'appliquent à des environnements GitHub spécifiques au sein du dépôt, comme le développement et la 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'y a aucun moyen de définir secrets spécifiques à l'utilisateur. Si vous souhaitez 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 faire 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, y compris echo.
Utilisation des secrets GitHub
Pour définir un secret à l'échelle du référentiel, vous devrez vous diriger vers le panneau des paramètres du référentiel, puis 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 des noms secrets est en majuscules avec des traits de soulignement, également connus sous le nom de "cas de serpent hurlant" mais ce n'est pas appliqué par quoi que ce soit.
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 “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 aux secrets de 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 il s'agit du système le plus sécurisé et le plus flexible.
< /p>
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 avoir “administrateur” l'accès à 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.
LIRE LA SUITE
- › Économisez 10 % sur l'énorme bibliothèque de polices Premium de Monotype dès maintenant
- › Votre adresse IP a été temporairement bloquée : 7 façons de la réparer
- › La tablette Fire HD 10 de 64 Go d'Amazon est plus de la moitié réduite aujourd'hui
- › Comment créer des albums intelligents dans Apple Photos sur Mac
- › La fonction de restauration de Windows 11 fonctionnera bientôt avec plus d'applications
- › Retour sur les produits de réalité virtuelle qui n'ont jamais été à la hauteur