Étiquette : chiffrement

Chiffrement d’une image de container

Le chiffrement d’une image de container est un sujet assez peu évoqué. Les premiers exemples de solution n’apparaissant qu’à partir de 2019, poussé en particulier par Brandon Lum de IBM.

Le support de ces fonctionnalités ne semble pas très répandu pour le moment. Du côté des outils, nous parlons actuellement de buildah et skopeo pour la partie build, containerd et cri-o pour la partie runtime et enfin docker distribution pour la partie registry. A priori, il ne semble pas y avoir de support dans docker, mais un commentaire au détour d’une issue GitHub semblait indiquer que cela sera le cas. Je n’ai en revanche pas trouvé d’annonce ou de roadmap permettant de valider ce point.

Voici à la suite, les étapes de mon test de chiffrement d’une image de container, réalisé sous ArchLinux, mais transposable à toute autre distribution, à condition de pouvoir installer l’ensemble de dépendances.

Préparation

Installation des Dépendances

Sous ArchLinux, installation des composants:

$ sudo pacman -S docker containerd buildah podman minikube kubectl helm
$ sudo systemctl start docker
$ sudo gpasswd -a <user> docker

Registre d’image local

Démarrage d’un registre local pour y stocker l’image chiffrée que je vais générer.

$ sudo systemctl start docker  
$ sudo systemctl status docker
$ sudo docker run -d -p 5000:5000 --restart=always --name registry registry:2

Génération du couple de clé

$ openssl genrsa -out testKey.pem 2048
$ openssl rsa -in testKey.pem -pubout -out testKey.pub.pem

Création d’une image basique

$ mkdir app
$ cd app
$ nano Dockerfile
$ nano secret-file

Avec pour contenu du Dockerfile:

FROM nginx:latest
COPY secret-file /secret-file

Et secret-file, un simple fichier texte contenant une chaîne de caractère aléatoire.

Construction de l’image

$ sudo buildah bud -t encrypted-test .

Export

Export vers le registre local.

$ sudo buildah push --tls-verify=false --encryption-key jwe:../testKey.pub.pem encrypted-test localhost:5000/vvision/encrypted-test:latest

Export local dans une archive oci.

$ sudo buildah push --encryption-key jwe:../testKey.pub.pem  encrypted-test oci-archive:encrypted-test:latest

Nettoyage

Suppression de toutes les images locales.

$ sudo buildah rmi --all

Récupération de l’image

$ sudo buildah pull --tls-verify=false --decryption-key keys/testKey.pem localhost:5000/vvision/encrypted-test

Exécution

$ sudo podman run -it localhost:5000/vvision/encrypted-test
/bin/bashroot@3e3c1ccde93c:/# cat secret-file
ASecretSecret

Vérification

Tentative de récupération de l’image depuis le registre local, sans préciser la clef.

$ sudo buildah pull --tls-verify=false localhost:5000/vvision/encrypted-test Getting image source signatures
Copying blob 302a0c0a162e [--------------------------------------] 0.0b / 914.0b
Copying blob 83e2b8dcdf4b [--------------------------------------] 0.0b / 27.1MiB
Copying blob 9b30e9f5d77e [--------------------------------------] 0.0b / 617.0b
Copying blob 0f9f80250abf [--------------------------------------] 0.0b / 134.0b
Copying blob 7c9b3bc4d85b [--------------------------------------] 0.0b / 26.3MiB
Copying blob 538a8875d492 [--------------------------------------] 0.0b / 678.0b
Error decrypting layer sha256:83e2b8dcdf4bfca8bea0b23e771e84074e4cc308bf892bd6d63b3a0c9dab0564: missing private key needed for decryption

Utilisation dans Kubernetes

Démarrage d’un cluster Kubernetes avec minikube.

$ minikube start --network-plugin=cni --enable-default-cni --container-runtime=cri-o --bootstrapper=kubeadm --insecure-registry="<local_ip_addr>:5000"
$ minikube dashboard

Mécanisme de synchronisation des clefs

Installation du composant responsable déploiement de la clef de déchiffrement.

$ git clone https://github.com/IBM/k8s-enc-image-operator.git
$ cd k8s-enc-image-operator
$ kubectl create namespace enc-key-sync
$ helm install --namespace=enc-key-sync k8s-enc-image-operator ./helm-operator/helm-charts/enckeysync/

Ajout de la clé dans Kubernetes Secret

$ kubectl create -n enc-key-sync secret generic --type=key --from-file=testKey.pem test-decryption-key

Déploiement du container

$ kubectl run test-enc --image=localhost:5000/vvision/encrypted-test

Conclusion

Au moment de mes premiers tests, je ne crois pas avoir rencontré de difficulté à récupérer l’image dans le registre local. Néanmoins, lors de tests plus récents, je n’ai pas réussi à reproduire ce fonctionnement sur d’autres plateformes. En revanche, une récupération depuis le registre docker, ou celui proposé dans la Google Cloud Plateform fonctionne.

Il me reste maintenant à reproduire ce mécanisme sur un cas réel complet, c’est-à-dire, de l’intégration au processus et aux outils de CI/CD, à la configuration du cluster Kubernetes cible, avec pour objectif un déploiement de la solution en production.

Sources

Chiffrer un support

Je réfléchis ces derniers temps à ma résilience numérique. C’est un thème qui me tient à cœur, mais que je n’ai pas ou peu développé pour l’instant. Je me suis cantonné à y penser de temps à autre, sans faire beaucoup plus que m’assurer d’avoir un double de mes fichiers importants. J’ai néanmoins amélioré la partie service au premier semestre 2018, en automatisant le déploiement de mon nuage de service à partir de la dernière sauvegarde disponible. La solution fonctionne et a le mérite d’être une première étape pouvant servir de base pour des améliorations ultérieures. Plus récemment, je me suis donc intéressé à mes données locales, à commencer par ce que l’on pourra nommer les « fichiers critiques »: base de données de mot de passe, copie de documents administratifs, … Pour ces données, il convient de les sauvegarder sur de multiples supports qui pourront ensuite être stockés en des lieux différents. Ces supports ne doivent bien sûr pas être lisible, c’est pourquoi je fais le choix de les chiffrer. C’est cette opération que je vais documenter ci-dessous.

Création

Le support sera chiffré avec la combinaison LUKS/dm-crypt. Une fois l’emplacement du support identifié (/dev/sdx), on pourra effectuer l’opération de chiffrement avec cryptsetup : 

sudo cryptsetup --cipher aes-xts-plain64 --key-size 512 --hash sha512 luksFormat /dev/sdx

Attention, cette commande effacera toutes les données sur le support concerné ! Par ailleurs, en ce qui concerne le choix de la phrase secrète, la documentation de cryptsetup conseille de se limiter aux 95 caractères imprimables des premiers 128 caractères de la table ASCII; pour des raisons d’encodage. Au revoir donc caractères accentués et autres caractères particuliers propres à la langue française.

Ouverture

Une fois le support chiffré, nous allons pouvoir l’ouvrir. 

sudo cryptsetup luksOpen /dev/sdx nomDuDisque_crypt

Sécurité supplémentaire (optionnel)

Avant de formater, certaines sources préconisent de remplir le support de zéro. Avec le programme dd et une indication de la progression :

dd if=/dev/zero of=/dev/mapper/nomDuDisque_crypt status=progress

Attention, cette opération n’est pas des plus rapides et peut durer plusieurs heures.

Formatage

Et enfin formater le support. 

sudo mkfs.ext4 -L nomDuDisque /dev/mapper/nomDuDisque_crypt

Statut

On peut vérifier le statut du support : 

sudo cryptsetup -v status nomDuDisque

Qui nous donnera : 

/dev/mapper/nomDuDisque is active.   type:    LUKS1   cipher:  aes-xts-plain64   keysize: 512 bits   key location: dm-crypt   device:  /dev/sdx   sector size:  512   offset:  4096 sectors   size:    30229492 sectors   mode:    read/write Opération réussie.

Fermeture

Pour fermer le support chiffré : 

sudo cryptsetup luksClose /dev/mapper/nomDuDisque_crypt

Sauvegarde du header

Étant donné que toute corruption, altération ou destruction du header LUKS entraîne l’impossibilité d’accéder à l’ensemble du support chiffré, il convient d’en effectuer une sauvegarde : 

cryptsetup luksHeaderBackup --header-backup-file /chemin/vers/header /dev/sdx

Il faut renouveler la sauvegarde du header en cas de changement des phrases secrètes (un support chiffré peut avoir jusqu’à 8 phrases secrètes différentes).

Test d’un header

En cas de tentative de restauration d’un header, il est possible de vérifier que le header que l’on souhaite restaurer est le bon : 

sudo cryptsetup -v --header /chemin/vers/header open /dev/sdx test

Qui doit renvoyer : 

Key slot 0 unlocked. Command successful.

Restauration d’un header

Avec le support fermé, on peut effectuer la restauration du header à partir de son fichier de sauvegarde : 

sudo cryptsetup luksHeaderRestore /dev/sdx --header-backup-file /chemin/vers/header

Gestion des phrases secrètes

Pour ajouter un mot de passe au support ou en supprimer un existant, on utilisera l’une des commandes : 

$ sudo cryptsetup luksAddKey /dev/sdx
$ sudo cryptsetup luksRemoveKey /dev/sdx

Note : Permissions ext4

Petit point technique relatif au système de fichier avant de conclure. Il faut noter que par défaut, suite au formatage, le propriétaire de la racine du support chiffré est root. En l’état, impossible sur mon système de déplacer un fichier vers le support chiffré sans passer par un sudo cp. Pour y remédier, on peut au besoin changer le propriétaire : 

sudo chown -R user /run/media/user/nomDuDisque

Il est également possible de donner les droits à l’utilisateur exécutant la commande de formatage via sudo avec : 

sudo mkfs.ext4 -E root_owner=$UID:$GID /dev/sdx

Ou encore : 

sudo mkfs.ext4 -E root_owner=$UID:$GID -L nomDisque /dev/mapper/nomDuDisque

Source: Format ext4 filesystem to be owned by regular user

Conclusion

À la suite de cet article, je dispose désormais d’un lot de clés USB chiffrées sur lesquelles je vais pouvoir stocker mes fichiers importants à sauvegarder. Afin de boucler la boucle, chaque header fera évidemment partie de la sauvegarde. Il me reste à définir la fréquence de rotation de ces sauvegardes froides, celle-ci sera certainement semestrielle, éventuellement trimestrielle. Chaque lieu de sauvegarde prévu disposant de deux clés dédiés, il suffira de générer la « nouvelle » clé, puis de l’échanger avec « l’ancienne ». Pour la suite, je souhaite conduire une réflexion sur mes données locales: définir clairement les fichiers critiques, définir une arborescence générale pour l’organisation de mes données. Il sera également nécessaire de s’interroger sur la pertinence des données (données à garder ?) et de définir quelles données constituent éventuellement une perte acceptable, afin de choisir le disque externe à privilégier (en fonction de son âge principalement).

Source :