Come posso gestire i segreti in .tf e .tfstate?

Vorrei utilizzare il provider MySQL Terraform per tenere un elenco di utenti mysql e concessioni utili per la creazione di nuovi ambienti di test. L' .tfe .tfstatefile entrambi sembrano voler archiviare le password in chiaro MySQL.

Per quanto riguarda .tf:

Comprendo che i .tffile vivono nel controllo di revisione e sono gestiti da un team. In che modo questa pratica differisce quando ci sono segreti .tf? È possibile crittografare questi valori?

Per quanto riguarda .tfstate:

Posso archiviare in .tfstatemodo sicuro da qualche parte dopo aver eseguito l'applicazione Terraform, ma sarebbe preferibile per questo caso d'uso non memorizzarlo affatto?

Terraform supporta l' aggiunta di un file aggiuntivo con variabili durante l'invocazione.

^{documentazione: https://www.terraform.io/intro/getting-started/variables.html#from-a-file}

Stiamo usando quella funzione per fornire un secrets.tfvarsfile su ogni invocazione di Terraform. Usiamo anche uno script per avvolgere il comando in modo che la sua invocazione sia coerente e tutti i membri del team evitino di dover fare gli stessi errori. Il wrapper si sincronizza .tfstatecon S3 prima di un'esecuzione e .tfstatealla fine torna a S3. Ho anche sentito di persone che fanno la stessa cosa con lo stato immagazzinato nel Console, aggiungendo persino una specie di semaforo nel console per impedire a due persone di avviare Terraform contemporaneamente.

Quando si evita di impostare un valore predefinito in un variables.tffile, si forza l'utente a immettere il valore. Può essere inserito manualmente o usando l' -var-fileopzione di comando come descritto sopra. Non impostare un valore predefinito sui tuoi segreti è un buon modo per applicare le modifiche che richiedono un cambiamento nei segreti.

Il secrets.tfvarsfile è un collegamento simbolico a uno dei file con segreti che non sono memorizzati nel controllo versione. Abbiamo diversi, uno per ogni ambiente, in questo modo secrets-prod.tfvars, secrets-dev.tfvars, secrets-stg.tfvars, ecc ...

Una pratica ancora migliore sarebbe quella di generare questi file segreti durante lo script wrapper basato sui dati in Vault o in qualche altro modo per condividere i segreti. Da quando attualmente il formato dei segreti cambia, o segreti stessi, dobbiamo comunicarlo al team al di fuori del canale di controllo della versione - e questo non sempre funziona bene, per essere onesti. Ma i segreti cambiano raramente.

Evitiamo che terraform gestisca i nostri segreti. Anche se riesci a iniettare segreti con un file var "secrtes.tfvars" come indicato sopra, questi segreti saranno memorizzati nel tuo stato terraform (remoto).

È possibile proteggere i file di stato remoti utilizzando ad esempio l'autorizzazione S3 oppure è possibile gitignore i file di stato locali ma abbiamo deciso di non fare affidamento su questo tipo di protezione.

Se sei su AWS, dai un'occhiata a "The Right Way to Manage Secrets" di Segment.io sul blog AWS. Sosteniamo l'utilizzo chamberdi tutti i nostri clienti per la gestione dei segreti. Funziona sfruttando il Parameter Store (SSM) di AWS Systems Manager insieme alle chiavi KMS. Ciò garantisce che i segreti siano crittografati a riposo (e in transito), protetti con IAM, verificabili con CloudTrails ed esposti solo come variabili di ambiente in fase di esecuzione.

Dopo aver configurato la camera e impostato la chiave KMS, scriviamo i segreti nell'archivio parametri.

chamber write db TF_VAR_DB_USER foobar
chamber write db TF_VAR_DB_PASS secret

Quindi usa quei segreti quando chiami terraform.

chamber exec db -- terraform plan

Ciò presuppone che tu abbia definito una variabile chiamata DB_USERe DB_PASSnel tuo codice HCL.

Ad esempio, è possibile aggiungere questo a variables.tf

variable "DB_USER" { }
variable "DB_PASS" { }

NOTA: chamber verranno sempre esportate le variabili di ambiente in maiuscolo

Forniamo un modulo terraform chiamato terraform-aws-kms-keyper semplificare il provisioning della chiave KMS. Consulta la nostra documentazione dettagliata con esempi di come utilizzare chambercon più spazi dei nomi e come utilizzare Chamber con Terraform per gestire i segreti. Consulta il nostro esempio di riferimento completo per le dipendenze della camera di provisioning.

Per quanto riguarda .tfstate, fai apparire un ottimo punto sull'esistenza di segreti in chiaro nel file di stato. Non c'è davvero modo di aggirare questo. Affinché terraform calcoli le modifiche per costruire un piano, deve conoscere lo stato "prima" e "dopo". Per questo motivo, si consiglia di utilizzare un bucket S3 crittografato con versioning obbligatorio. Utilizzare il terraform-aws-tfstate-backendmodulo per eseguire il provisioning di un bucket e di una tabella di blocco DynamoDB in base alle best practice.

Per importare segreti in file .tf, è anche possibile utilizzare un'origine dati esterna . Questo potrebbe essere ad esempio uno script che decodifica i tuoi segreti.

Ho guardato in diversi modi ma mi è piaciuta particolarmente git-crypt per una cosa ad hoc da fare prima di implementare qualcosa di più grande come Vault.