Cryptage Python

Photo by Towfiqu barbhuiya on Unsplash

Une perspective DevOps sur la sécurisation des paramètres de déploiement Public-key

Les builds de code et l'automatisation du déploiement ont ouvert la voie à de nombreuses grandes choses. L'époque des versions mensuelles et manuelles du code est révolue depuis longtemps ; les pipelines CI/CD modernes ont désormais la possibilité de publier chaque validation de code qui passe les tests automatisés dans les environnements de développement et de mise en production vers la production.

Pour que cette magie opère, les équipes DevOps doivent créer un code indépendant de l'environnement. Le même code doit être déployé dans DEV, TEST, STAGE, puis dans PROD, en transmettant les paramètres appropriés au moment du déploiement pour que la solution se comporte de manière appropriée. L'architecture des microservices et le découplage des sous-composants indépendants qui doivent se découvrir après avoir été déployés pour travailler ensemble en font une tâche très difficile. Garder une trace de ces paramètres de déploiement, la "colle" qui fera fonctionner ensemble tous ces composants naïfs dans n'importe quel environnement donné, est devenu un nouveau défi en soi.

Bien qu'il soit de notoriété publique, cela ne peut probablement pas faire de mal de le répéter une fois de plus : vous ne devez jamais, en aucun cas, intégrer des informations d'identification de quelque nature que ce soit, y compris des clés d'API, dans votre code ou une image de conteneur. Les informations d'identification téléchargées dans un référentiel de code ou un registre d'images doivent être considérées comme ayant été compromises et modifiées immédiatement.

Mais, vous vous demandez peut-être : si vous ne pouvez pas suivre ces précieux paramètres de déploiement dans un référentiel de code source, que pouvez-vous faire ? Conserver ces valeurs critiques dans un référentiel sous contrôle de version est une bonne idée, mais tant qu'elles sont chiffrées. La cryptographie à clé publique/privée fournit la meilleure solution car le secret chiffré ne peut pas être déchiffré sans la clé privée, de sorte qu'ils peuvent être téléchargés en toute sécurité vers un référentiel GitHub privé tant que la clé de déchiffrement ne l'est pas.

Les bons vieux fichiers de configuration ou fichiers ".INI" sont étonnamment bien adaptés pour stocker les paramètres de déploiement car ils permettent de stocker le même nom de clé avec des valeurs différentes dans plusieurs sections représentant les différents environnements. Par exemple:

La valeur de mon nom d'utilisateur de base de données db_user sera la même pour toutes les sections (DEFAULT) mais la valeur de db_pwd peut être différente dans DEV que dans PROD.

La bibliothèque Python rsa_crypto et l'utilitaire de ligne de commande vous permettent de combiner la flexibilité du stockage des valeurs dans les fichiers de configuration avec la sécurité du chiffrement à clé privée/publique. Des fichiers binaires autonomes pour Windows, Mac et Linux sont également disponibles pour plus de commodité.

La première étape consiste à générer de nouvelles clés :

Par défaut, l'outil crée une nouvelle paire de clés RSA 4096 bits (secrète) et l'enregistre dans un fichier unique, protégé par un mot de passe répondant à la norme PKCS # 8 et utilisant la fonction de dérivation de clé scrypt pour contrecarrer les attaques par force brute par dictionnaire. La clé est sécurisée avec un bon mot de passe, mais elle ne doit toujours jamais être stockée dans un référentiel de code.

Avoir encore un autre mot de passe ne se prête pas bien à l'automatisation du déploiement. L'outil fournit également un moyen d'extraire ce fichier protégé par mot de passe dans des fichiers de clé publics et privés séparés qui ne nécessitent pas de mot de passe.

Le fichier de clé publique peut être distribué en toute sécurité à quiconque doit pouvoir chiffrer des valeurs, il ne peut pas être utilisé pour le déchiffrement. Il s'agit d'une excellente option car les informations d'identification sont généralement gérées par un groupe distinct dans la plupart des organisations.

Inversement, la clé privée doit être gardée avec une extrême prudence car elle peut être utilisée pour déchiffrer n'importe quelle valeur sans mot de passe. L'outil recherchera ces fichiers clés dans le répertoire courant (celui à partir duquel vous exécutez la commande), le répertoire où se trouve le script, ainsi que dans le répertoire personnel de l'utilisateur. Il recherchera également les fichiers clés en tant que variables d'environnement, ce qui pourrait être une meilleure option dans de nombreuses situations.

Le fichier de clé privée peut alors être supprimé en toute sécurité, il peut toujours être regénéré à partir du fichier de clé chiffré par mot de passe :

L'outil peut également être utilisé avec l'option -k pour spécifier un préfixe de nom de clé différent, permettant aux utilisateurs d'avoir plusieurs clés pour différents environnements ou objectifs ou des informations d'identification gérées par différentes équipes :

Ces paramètres get et set du script peuvent également être utilisés pour stocker et récupérer des valeurs chiffrées dans un fichier de configuration. Le fichier de configuration doit déjà exister :

La structure du fichier est assez simple, il contient des sections délimitées par des crochets [MA_SECTION]. Notez que le nom de la section peut être sensible à la casse. La section [DEFAULT] est utilisée par défaut.

Chaque section contiendra alors plusieurs "options" et valeurs (couples clé/valeur). Seule la valeur sera cryptée, le nom de l'option restera en clair.

Cette structure est très bien adaptée pour garder une trace des valeurs qui doivent être différentes selon l'environnement, comme pour garder une trace des mots de passe de base de données dans un environnement DEV, TEST et PRODUCTION.

Pour enregistrer une valeur d'une option nommée database_password dans la section DEV à l'aide de la clé de chiffrement par défaut :

Si vous ne spécifiez pas de valeur, le script vous demandera la valeur afin qu'elle ne soit pas visible dans l'historique de la ligne de commande. En option, si vous préférez, vous pouvez également spécifier la valeur en tant que paramètre de ligne de commande à l'aide du paramètre -v.

Pour déchiffrer la valeur :

Notez que dans l'exemple ci-dessus, la clé privée rsa_private.pem nous a permis de déchiffrer les données sans demander de mot de passe. Encore une fois, soyez extrêmement prudent car toute personne disposant de ce fichier peut décrypter les données . Si la clé privée n'est pas présente, le script demandera alors un mot de passe pour ouvrir le fichier de paire de clés protégées rsa_key.bin.

Maintenant, définissons et récupérons le mot de passe PROD :

Le contenu du fichier de configuration .rsa_values.conf ressemblera à ceci :

L'outil peut également être utilisé pour chiffrer des fichiers entiers, tels qu'un fichier de configuration Kubernetes Parameter Store .yaml, à l'aide de l'option -f.