Introduction
Dans le laboratoire précédent, notre assistant robot s’est connecté automatiquement à un entrepôt. Mais d’où tenait-il le mot de passe ?
Dans les automatisations réelles, les workflows ont souvent besoin de données sensibles telles que des clés d’API, des mots de passe ou des jetons. Vous ne devez jamais coder ces valeurs en dur dans les fichiers du dépôt.
GitHub fournit les Secrets, un mécanisme de stockage protégé pour les valeurs sensibles utilisées par les workflows. Il s’agit d’une pratique essentielle de sécurité CI/CD, car les pipelines ont souvent besoin d’un accès privilégié.
C’est l’une des limites les plus importantes en matière de sécurité des automatisations. Les pipelines ont besoin d’identifiants, mais ceux-ci doivent être injectés au moment de l’exécution depuis un stockage protégé, et non enregistrés dans le contrôle de version.
Dans ce laboratoire, vous allez :
- Créer un mot de passe secret dans le coffre-fort.
- Apprendre au robot à le récupérer.
- Vérifier que même si le robot essaie d’afficher le mot de passe, GitHub le masquera.
Prérequis
Nous allons continuer à utiliser le dépôt github-actions-basics.
Créer un secret
Imaginons que notre application doive se connecter à une base de données. Nous devons stocker le mot de passe de la base de données en toute sécurité.
Nous allons créer un secret nommé DB_PASSWORD.
- Ouvrez votre dépôt
github-actions-basicssur GitHub. - Cliquez sur l’onglet Settings.
- Dans la barre latérale gauche, repérez l’élément de menu Secrets and variables, puis cliquez dessus pour le développer.
- Sélectionnez Actions.
- Cliquez sur le bouton vert New repository secret.
Un formulaire simple s’affiche :
- Name : saisissez
DB_PASSWORD. (Il est courant d’utiliser uniquement des majuscules pour les noms de secrets.) - Secret : saisissez
SuperSafePassword123!.
Cliquez sur Add secret.
DB_PASSWORD devrait maintenant apparaître dans la liste. Notez que vous ne pouvez plus voir sa valeur. Une fois qu’un secret est enregistré, il est définitivement mis à l’abri. Vous pouvez le modifier ou le supprimer, mais vous (comme toute autre personne) ne pourrez plus jamais consulter sa valeur.
Utiliser le secret
Maintenant que le mot de passe est dans le coffre-fort, écrivons un workflow pour l’utiliser.
Le principe important ici est l’indirection : le workflow référence un secret par son nom, et GitHub résout sa valeur de manière sécurisée pendant l’exécution.
Dans votre fichier de workflow, vous pouvez accéder à n’importe quel secret avec la syntaxe ${{ secrets.YOUR_SECRET_NAME }}.
Accédez au répertoire de votre projet.
cd ~/project
git clone https://github.com/your-username/github-actions-basics.git
cd github-actions-basics
Remarque : remplacez your-username par votre nom d’utilisateur GitHub réel.
Créez un fichier de workflow nommé security-test.yml dans le dossier .github/workflows.
touch .github/workflows/security-test.yml
Ouvrez-le avec nano.
nano .github/workflows/security-test.yml
Ajoutez le contenu suivant :
name: Security Test
on: [push]
jobs:
test-secret:
runs-on: ubuntu-latest
steps:
- name: Try to print secret
env:
MY_PASSWORD: ${{ secrets.DB_PASSWORD }}
run: echo "The password is $MY_PASSWORD"
Ici, nous faisons quelque chose d’intéressant. Nous transférons le secret du coffre-fort GitHub vers une variable d’environnement nommée MY_PASSWORD. Ensuite, nous essayons de l’afficher avec echo.
Attendez ! Afficher un mot de passe dans les journaux n’est-il pas une très mauvaise idée ? Si, bien sûr ! Mais nous le faisons pour démontrer une fonction de sécurité puissante de GitHub Actions.
Enregistrez le fichier et quittez nano.
Vérifier le masquage
Exécutons ce workflow et voyons ce qui se passe lorsque nous essayons de divulguer un secret.
Validez et envoyez vos modifications.
git add .
git commit -m "Test secret masking"
git push
Accédez à Actions dans votre dépôt sur GitHub.
- Cliquez sur l’exécution du workflow « Security Test ».
- Cliquez sur le job
test-secret. - Développez l’étape « Try to print secret ».
Observez la sortie. Vous devriez voir quelque chose comme ceci :
The password is ***
GitHub Actions a automatiquement reconnu que la valeur de $MY_PASSWORD provenait d’un secret. Avant d’écrire quoi que ce soit dans le journal, il recherche cette valeur sensible et la remplace par ***.
Le masquage limite les conséquences d’une divulgation accidentelle dans les journaux, mais il reste préférable de ne jamais afficher de secrets. Les fonctions de sécurité constituent un filet de protection, et non une excuse pour les manipuler sans précaution.
Cette fonction de « masquage » vous protège. Même si vous essayez accidentellement d’afficher un secret ou si un outil que vous utilisez est trop verbeux, GitHub le détecte et efface les données sensibles des journaux.
À propos de GITHUB_TOKEN : souvenez-vous de ${{ secrets.GITHUB_TOKEN }}, que nous avons utilisé dans le laboratoire précédent. Il fonctionne exactement de la même manière. Il s’agit d’un secret que GitHub crée automatiquement pour chaque exécution, et sa valeur est également masquée dans les journaux.
Résumé
Dans ce laboratoire, vous avez appris les notions essentielles de la sécurité des automatisations.
- Coffre-fort : vous avez utilisé les secrets GitHub pour stocker des données sensibles telles que des mots de passe.
- Accès : vous avez utilisé
${{ secrets.NAME }}pour donner à votre robot un accès par badge à ces données. - Masquage : vous avez vérifié que GitHub caviarde automatiquement les secrets dans les journaux (
***) afin d’éviter les divulgations accidentelles.
Vous disposez maintenant d’un pipeline sécurisé et automatisé. Dans le dernier laboratoire, nous aborderons l’objectif ultime du DevOps : le déploiement continu. Nous apprendrons à faire déployer votre code par votre robot sur un serveur en production !
