Docker secrets : utiliser votre clé SSH pendant le build

Il y a beaucoup d'articles sur Internet mais je n'ai pas trouvé celui qui m'aurait permis, sans une quantité impressionnante d'essais et d'erreurs, de trouver la solution.

Voici donc un article de plus à ajouter à la longue liste : comment accéder à un projet privé stocké sur Github lors de la création d'une image Docker. Autrement dit, la clé SSH n'est pas stockée dans l'image. Docker utilisera juste votre clé lors de l'exécution du layer de récupération du projet (celui qui contient l'instruction git clone) et n'en gardera aucune trace ensuite.

Mon cas d'usage : je veux construire une image Docker et pendant la phase de build, j'ai besoin de récupérer une copie d'un repository privé que j'ai mis sur github.com. L'équivalent CI de ce problème — récupérer une image Docker privée plutôt qu'un repository privé — est traité dans GitLab - Utiliser des images Docker privées.

Quand j'accède au container, le projet sera bien présent mais je n'ai, nulle part dans mon image, de copie de ma clé SSH. Je ne pourrai donc pas lancer un git pull par exemple, puisque plus aucune authentification n'est possible.

Aperçu​

C'est la preuve que la technique fonctionne : la clé SSH a servi à s'authentifier auprès de GitHub pendant le build — sans jamais être inscrite dans l'image finale.

Pourquoi ça fonctionne​

• Le RUN --mount=type=secret de Docker monte le secret uniquement pendant la durée de ce layer de build — il n'est jamais écrit dans un layer qui se retrouve dans l'image finale.
• Copier votre clé SSH dans l'image (ou coder en dur un token) est une grave erreur de conception : n'importe qui lisant le Dockerfile, ou démarrant une session bash interactive pour lancer printenv ou parcourir les dossiers .ssh/.git, la trouvera.
• Même un secret supprimé dans un layer ultérieur peut survivre : des outils comme SecretScanner scannent en profondeur, layer par layer, et le retrouveront s'il a été écrit sur le disque dans un layer précédent. Le même raisonnement s'applique à votre historique git : Git - pre-commit-hooks liste des hooks qui bloquent un commit dès qu'un identifiant est détecté.

Quelle clé utiliser​

Il est important de savoir quelle clé a été utilisée pour lier votre profil Github.

Vous pouvez simplement afficher le fichier dans votre console, par exemple cat ~/.ssh/id_ed25519.pub ou cat ~/.ssh/id_rsa.pub (le fichier de clé publique) et regarder la fin : l'email mentionné est-il celui que vous utilisez sur Github.com ? Si oui, vous avez probablement identifié la bonne clé.

Dans mon cas, la clé que j'utilise pour github.com est id_ed25519, je vais donc utiliser celle-là dans le chapitre suivant.

Création des fichiers​

Nous aurons besoin de deux fichiers : compose.yaml et Dockerfile.

compose.yaml​

Voici le contenu de mon compose.yaml :

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      // highlight-next-line
      secrets:?
        // highlight-next-line
        - my_ssh_key?
      args:
        // highlight-next-line
        - KEY_NAME=id_ed25519?

// highlight-next-line
secrets:
  // highlight-next-line
  my_ssh_key:?
    // highlight-next-line
    file: ${HOME}/.ssh/id_ed25519?

Comme vous pouvez le voir, il y a cinq lignes spécifiques.

Dans notre entrée services -> app --> build, nous devons ajouter secrets et le nom d'un (ou plusieurs) secrets.

J'ai aussi ajouté un argument appelé KEY_NAME simplement parce que je dois indiquer à Docker quelle clé j'utilise (est-ce id_ed25519, id_rsa ou une autre).

Les secrets doivent être définis au même niveau d'indentation que services et la notation est celle-ci :

secrets:
  a_secret_name:
    file: existing_file?

Vous pouvez mettre ce que vous voulez pour a_secret_name ; par exemple, my_ssh_key.

Dockerfile​

Il est temps de créer notre deuxième fichier, Dockerfile :

FROM alpine:3.19

ARG KEY_NAME="id_rsa"?

USER root

RUN apk add --no-cache bash ca-certificates git openssh-client?

// highlight-next-line
RUN mkdir -p -m 0700 /root/.ssh && ssh-keyscan "github.com" >> /root/.ssh/known_hosts?

// highlight-next-line
RUN --mount=type=secret,id=my_ssh_key,dst=/root/.ssh/${KEY_NAME} \?
    // highlight-next-line
    mkdir -p /app && cd /app \
    // highlight-next-line
    && ssh -T git@github.com || true \?
    // highlight-next-line
    && git clone git@github.com:cavo789/my_private_repo.git

WORKDIR /app

# Keep the container running
ENTRYPOINT ["tail", "-f", "/dev/null"]?

Comme vous pouvez le voir, nous définissons KEY_NAME="id_rsa" comme valeur par défaut (mais elle sera écrasée par notre déclaration dans le fichier yaml) puis, plus loin, nous créons le dossier /root/.ssh et nous ajoutons github.com à la liste des hosts connus.

Le plus important vient ensuite. Nous devons utiliser la syntaxe RUN --mount=type=secret pour indiquer à Docker que ce layer va utiliser un secret Docker. Nous devons fournir le nom de notre secret (défini dans notre fichier yaml, ici my_ssh_key) puis définir où ce secret doit être stocké pendant ce layer. Notre variable KEY_NAME trouve son utilité ici : notre clé SSH était id_ed25519 et c'est la valeur de la variable KEY_NAME.

Donc, en bref, --mount=type=secret,id=my_ssh_key,dst=/root/.ssh/${KEY_NAME} sera traduit en --mount=type=secret,id=my_ssh_key,dst=/root/.ssh/id_ed25519.

Pendant ce layer donc, notre clé SSH locale sera enregistrée dans /root/.ssh/id_ed25519. Les autres lignes de ce layer RUN vont d'abord créer un dossier /app, s'y placer, puis lancer ssh -T git@github.com juste pour le débogage (nous nous attendons à voir à l'écran Hi your_name! You've successfully authenticated) et enfin nous clonons notre repository privé en SSH.

Créer l'image et entrer dans le container​

Bon, vous avez donc créé les deux fichiers sur votre disque dur.

Lancez docker compose --progress plain build --no-cache dans votre console pour construire l'image en activant le mode verbeux.

Comme vous pouvez le voir, nous pouvons confirmer que notre clé SSH a bien été partagée pendant le build — c'est la sortie « You're authenticated » montrée en haut de cet article.

Vous allez maintenant créer le container, en lançant docker compose up --detach.

Maintenant, juste pour vérifier, nous pouvons entrer dans le container en lançant docker compose exec app /bin/bash.

Nous pouvons vérifier que notre clé n'a pas été stockée dans l'image en lançant ls -alh /root/.ssh/

On peut aussi vérifier autrement : aller dans le dossier de notre projet et lancer git pull échouera avec l'erreur ci-dessous :

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
▋

Et c'est exactement ce qu'on attend : notre clé ne fait pas partie de l'image, donc on ne peut plus se connecter à Github.

Partager aussi vos clés avec le container​

Bon, nous avons vu comment partager la clé SSH avec Docker mais uniquement pendant la phase de build. Comme vu plus haut, entrer dans le container et lancer git pull a échoué ; exactement ce que nous voulions dans le chapitre précédent.

Mais maintenant, si nous avons besoin de partager notre clé aussi avec le container pour pouvoir travailler sur le projet, le mettre à jour et pousser des changements / récupérer des modifications, comment faire ?

Éditez le fichier compose.yaml et ajoutez ces deux lignes :

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      secrets:?
        - my_ssh_key?
      args:?
        - KEY_NAME=id_ed25519
    // highlight-next-line
    volumes:
      // highlight-next-line
      - ${HOME}/.ssh:/root/.ssh?

secrets:
  my_ssh_key:
    file: ${HOME}/.ssh/id_ed25519?

Puis recréez le container en lançant docker compose up --detach. Entrez dans le container avec docker compose exec app /bin/bash et allez dans le dossier de votre projet. Maintenant, en lançant git pull, vous verrez que ça fonctionne.

Pourquoi ? Parce que vos clés SSH font maintenant partie du container, comme on peut le voir en lançant ls -alh /root/.ssh :

services:
  app:
    [...]
    // highlight-next-line
    volumes:
      // highlight-next-line
      - ${HOME}/.ssh:/root/.ssh?

services:
  app:
    [...]
    // highlight-next-line
    volumes:
      // highlight-next-line
      - ${HOME}/.ssh:/christophe/.ssh?

Conclusion​

Deux besoins différents, deux mécanismes différents : un secret de build (--mount=type=secret) qui ne touche jamais l'image finale, pour des opérations ponctuelles comme cloner un repo privé pendant docker build ; et un volume bind-monté, pour quand le container en cours d'exécution a besoin de votre clé de façon continue pour git pull/push. Choisissez le premier par défaut, et n'ajoutez le second que quand vous devez réellement travailler depuis l'intérieur du container.