La gestion des mots de passe dans les référentiels peut être traitée de différentes manières en fonction de votre problème exact.
1. Ne le faites pas.
Et les moyens d'éviter cela sont couverts dans certaines réponses - .gitignore, config.example, etc.
ou 2. Rendre le référentiel accessible uniquement aux personnes autorisées
C'est-à-dire les personnes qui sont autorisées à connaître le mot de passe. chmod et les groupes d'utilisateurs me viennent à l'esprit, ainsi que des problèmes tels que les employés de Github ou d'AWS doivent-ils être autorisés à voir des choses si vous hébergez vos référentiels ou vos serveurs en externe ?
ou 3. Crypter les données sensibles (objet de cette réponse)
Si vous voulez stocker vos fichiers de configuration contenant des informations sensibles (comme des mots de passe) dans un endroit public, il faut les crypter. Les fichiers peuvent être décryptés lorsqu'ils sont récupérés dans le référentiel, ou même utilisés directement à partir de leur forme cryptée.
Un exemple de solution javascript pour utiliser des données de configuration cryptées est présenté ci-dessous.
const fs = require('fs');
const NodeRSA = require('node-rsa');
let privatekey = new NodeRSA();
privatekey.importKey(fs.readFileSync('private.key', 'utf8'));
const config = privatekey.decrypt(fs.readFileSync('config.RSA', 'utf8'), 'json');
console.log('decrypted: ', config);
![Decrypted Config File]()
Vous pouvez donc récupérer un fichier de configuration crypté en écrivant seulement quelques lignes de Javascript.
Notez que mettre un fichier config.RSA dans un dépôt git en ferait effectivement un fichier binaire et perdrait ainsi beaucoup des avantages de quelque chose comme Git, par exemple la possibilité de sélectionner les modifications.
La solution pourrait être de crypter les paires clé-valeur ou peut-être seulement les valeurs. Vous pouvez crypter toutes les valeurs, par exemple si vous avez un fichier séparé pour les informations sensibles, ou crypter uniquement les valeurs sensibles si vous avez toutes les valeurs dans un seul fichier. (voir ci-dessous)
Mon exemple ci-dessus est un peu inutile pour quiconque veut faire un test avec, ou comme exemple pour commencer, car il suppose l'existence de quelques clés RSA et d'un fichier de configuration crypté. config.RSA .
Voici donc quelques lignes de code supplémentaires ajoutées pour créer des clés RSA et un fichier de configuration pour jouer avec.
const fs = require('fs');
const NodeRSA = require('node-rsa');
/////////////////////////////
// Generate some keys for testing
/////////////////////////////
const examplekey = new NodeRSA({b: 2048});
fs.writeFileSync('private.key', examplekey.exportKey('pkcs8-private'));
fs.writeFileSync('public.key', examplekey.exportKey('pkcs8-public'));
/////////////////////////////
// Do this on the Machine creating the config file
/////////////////////////////
const configToStore = {Goodbye: 'Cruel world'};
let publickey = new NodeRSA();
publickey.importKey(fs.readFileSync('public.key', 'utf8'));
fs.writeFileSync('config.RSA', publickey.encrypt(configToStore, 'base64'), 'utf8');
/////////////////////////////
// Do this on the Machine consuming the config file
/////////////////////////////
let privatekey = new NodeRSA();
privatekey.importKey(fs.readFileSync('private.key', 'utf8'));
const config = privatekey.decrypt(fs.readFileSync('config.RSA', 'utf8'), 'json');
console.log('decrypted: ', config);
Chiffrement des valeurs uniquement
fs.writeFileSync('config.RSA', JSON.stringify(config,null,2), 'utf8');
![enter image description here]()
Vous pouvez décrypter un fichier de configuration avec des valeurs cryptées en utilisant quelque chose comme ceci.
const savedconfig = JSON.parse(fs.readFileSync('config.RSA', 'utf8'));
let config = {...savedconfig};
Object.keys(savedconfig).forEach(key => {
config[key] = privatekey.decrypt(savedconfig[key], 'utf8');
});
Avec chaque élément de configuration sur une ligne séparée (par exemple Hello y Goodbye ci-dessus), Git reconnaîtra mieux ce qui se passe dans un fichier et stockera les modifications des éléments d'information sous forme de différences plutôt que de fichiers complets. Git sera également capable de mieux gérer les fusions, les cherry picks, etc.
Cependant, plus vous souhaitez contrôler les modifications apportées aux informations sensibles, plus vous vous orientez vers une solution de REPOSITOIRE SÛR (2) et vous éloignez d'une solution d'INFO ENCRYPTÉE (3).
