Controle de revisão de arquivos de configuração sensíveis

Question

Considere um arquivo com permissões somente para leitura de usuário, por exemplo ...

-r--------+ admin secrets.txt

Como esse arquivo pode ser colocado sob controle de revisão, de modo que seu conteúdo permaneça secreto, até mesmo do administrador do controle de revisão?

    

Answer 1

Use o GPG para criptografar o arquivo antes de se comprometer com o repo.

Sim, é complicado (você não conseguirá diferenciar / mesclar / etc. sem descriptografar primeiro), mas não consigo conceber nenhuma outra maneira de esfolar esse gato.

    

Answer 2

Armazene os segredos em um arquivo separado (não sob controle de versão) e insira o conteúdo secreto no outro arquivo com um script ou uma ferramenta parecida com um Puppet.

Trabalhando de esta outra resposta , um exemplo simples poderia ser :

netjoin.sh.erb (armazenado no controle de versão):

#!/bin/sh
# Usage: netjoin.sh /path/to/samba/binary/net pdc-hostname
NET=$1
SERVER=$2
HOSTNAME='facter hostname'-'facter operatingsystem'
PASSWORD=<%= scope.function_generate("/etc/puppet/auth/getpwd", "ad", "netjoin") %>
${NET} rpc user delete ${HOSTNAME}\$ -U netjoin%${PASSWORD} -S ${SERVER}
${NET} rpc join -U netjoin%${PASSWORD} -S ${SERVER}
/bin/rm -f $0

/ etc / puppet / auth / getpwd (também pode ser armazenado no controle de versão):

#!/bin/bash
# /etc/puppet/auth/getpwd
if [ "$#" -ne 2 ]; then
    echo "Usage: $0 <db> <user>"
    exit 1
fi
if [ ! -x /usr/bin/pwgen ]; then
    echo "missing pwgen!" >&2
    exit 1
fi
workdir='dirname $0'
workfile="$workdir/passwd_$1"
[ ! -r $workfile ] && exit 2
get_name="$2"
# get password from storage
pwd='egrep "^${get_name}:" ${workfile} | cut -d: -f2-'
if [ "$pwd" = "" ]; then
    # generate new password & store it
    len=$((60 + $RANDOM % 9 ))
    pwd=$(/usr/bin/pwgen -s $len 1)
    echo "${get_name}:${pwd}" >> $workfile
fi
# echo password (without new line)
echo -n "$pwd"

/ etc / puppet / auth / passwd_ad (absolutamente não no controle de versão):

netjoin:0Gb2iHFsnXZUnsyr0XSMxVvJVJ64zqpBzLFZXEoss5XVM9vTHWgvLHokBKclC

    

Answer 3

Tenha cuidado quando você tiver arquivos sensíveis à versão com Perforce - como o Perforce não lida com a permissão de arquivo diferente do bit executável, dependendo da sua umask, você ficará surpreso ao ver as permissões do arquivo serem confundidas quando você as verificar no Perforce:

$ p4 init
Matching server configuration from 'perforce:1666':
case-sensitive (-C0), unicode (-xi)
Server lester-dvcs-1449094406 saved.
$ date > x 
$ l x      
-rw-rw-r--. 1 lester lester 30 Dec  3 09:13 x
$ chmod 400 x
$ l x        
-r--------. 1 lester lester 30 Dec  3 09:13 x
$ umask  
002
$ p4 add x; p4 submit -d add 
//stream/main/x#1 - opened for add
Submitting change 1.
Locking 1 files ...
add //stream/main/x#1
Change 1 submitted.
$ l x                        
-rw-rw-r--. 1 lester lester 30 Dec  3 09:13 x   <-- oops!

Se alguém tiver uma boa solução, sou todo ouvidos! Enquanto isso, estou usando o mercurial / git para atualizar meus arquivos secretos (/ etc na verdade) e empurrar o repositório para algum lugar seguro - pelo menos as permissões dos meus arquivos locais permanecerão inalteradas.