¿Cómo puedo administrar secretos en .tf y .tfstate?


46

Me gustaría usar Terraform MySQL Provider para mantener una lista de usuarios de mysql y ayudas para crear nuevos entornos de prueba. Los archivos .tfy .tfstateparecen querer almacenar las contraseñas de MySQL en texto sin formato.

Con respecto a .tf:

Tengo entendido que los .tfarchivos viven en control de revisión y son mantenidos por un equipo. ¿Cómo difiere esa práctica cuando hay secretos en el .tf? ¿Es posible encriptar estos valores?

Con respecto a .tfstate:

Puedo almacenarlo de .tfstateforma segura en algún lugar después de ejecutar Terraform apply, pero sería preferible para este caso de uso no almacenarlo en absoluto.

Respuestas:


22

Terraform admite agregar un archivo adicional con variables durante la invocación.

documentación: https://www.terraform.io/intro/getting-started/variables.html#from-a-file

Estamos utilizando esa función para proporcionar un secrets.tfvarsarchivo en cada invocación de Terraform. También usamos un script para ajustar el comando de modo que su invocación sea consistente y todos los miembros del equipo eviten tener que cometer los mismos errores. El reiniciador se sincroniza .tfstatecon S3 antes de una ejecución y .tfstateregresa a S3 al final. También escuché de personas que hacen lo mismo con el estado almacenado en Cónsul, incluso agregando una especie de semáforo en cónsul para evitar que dos personas inicien Terraform al mismo tiempo.

Cuando evita establecer un valor predeterminado en un variables.tfarchivo, obliga al usuario a ingresar el valor. Se puede ingresar manualmente o usando la -var-fileopción de comando como se describe anteriormente. No establecer un valor predeterminado en sus secretos es una buena manera de aplicar los cambios que requieren un cambio en los secretos.

El secrets.tfvarsarchivo es un enlace simbólico a uno de los archivos con secretos que no están almacenados en el control de versiones. Tenemos varios, uno por el medio ambiente, así como secrets-prod.tfvars, secrets-dev.tfvars, secrets-stg.tfvars, etc ...

Una práctica aún mejor sería generar estos archivos de secretos durante la secuencia de comandos del contenedor basándose en los datos de Vault u otra forma de compartir secretos. Dado que actualmente el formato de los secretos cambia, o los secretos en sí mismos, necesitamos comunicarlo al equipo fuera del canal de control de versiones, y esto no siempre funciona bien, para ser honesto. Pero los secretos cambian con poca frecuencia.



8

Evitamos que Terraform maneje nuestros secretos. Incluso si logra inyectar secretos mediante un archivo var "secrtes.tfvars" como se indicó anteriormente, estos secretos se almacenarán en su estado de terraformación (remota).

Puede proteger los archivos de estado remoto utilizando, por ejemplo, la autorización S3, o puede ignorar los archivos de estado locales, pero decidimos no confiar en este tipo de protección.


2
También consulte github.com/hashicorp/terraform/issues/516, que es donde rastrean el problema de los secretos que se
escapan del estado

6

Si está en AWS, eche un vistazo a "La forma correcta de administrar secretos" de Segment.io en el Blog de AWS. Recomendamos utilizar chambera todos nuestros clientes para administrar secretos. Funciona al aprovechar el almacén de parámetros de AWS Systems Manager (SSM) junto con las claves KMS. Esto garantiza que los secretos se cifren en reposo (y en tránsito), protegidos con IAM, auditables con CloudTrails y solo expuestos como variables de entorno en tiempo de ejecución.

Después de configurar la cámara y configurar la clave KMS, escribimos los secretos en el almacén de parámetros.

chamber write db TF_VAR_DB_USER foobar
chamber write db TF_VAR_DB_PASS secret

Luego usa esos secretos cuando llames terraform.

chamber exec db -- terraform plan

Esto supone que ha definido una variable llamada DB_USERy DB_PASSen su código HCL.

Por ejemplo, podría agregar esto a variables.tf

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

NOTA: chamber siempre exportará variables de entorno en mayúsculas

Proporcionamos un módulo de terraforma llamado terraform-aws-kms-keypara facilitar el aprovisionamiento de la clave KMS. Consulte nuestra documentación detallada con ejemplos de cómo usar chambercon múltiples espacios de nombres, así como cómo usar la cámara con terraform para administrar secretos. Vea nuestro ejemplo de referencia completo para aprovisionar dependencias de la cámara.

En cuanto a .tfstate, traes un punto realmente bueno sobre la existencia de secretos de texto sin formato en el archivo de estado. Realmente no hay forma de evitar esto. Para que Terraform calcule los cambios para construir un plan, necesita conocer el estado "antes" y "después". Por este motivo, recomendamos utilizar un bucket S3 cifrado con versiones obligatorias. Utilice el terraform-aws-tfstate-backendmódulo para aprovisionar un cubo y una mesa de bloqueo DynamoDB de acuerdo con las mejores prácticas.


Esto está muy relacionado con los servicios de AWS, que la pregunta no menciona y no parece realmente una respuesta para las infraestructuras locales o cualquier otra nube.
Tensibai

@tensibai, tienes razón. La pregunta original no proporciona suficiente información para determinar la plataforma operativa para hacer la mejor recomendación. Cada plataforma será diferente dependiendo de las capacidades de la plataforma. En prem o baremetal, los usuarios pueden considerar usar una combinación de Vault y Terraform Enterprise. El alcance de la implementación será mucho, mucho mayor. :)
Erik Osterman

Ya uso AWS Secrets Manager y no quiero usar la cámara y la tienda de parámetros. ¿Es posible hacer lo mismo con Secrets Manager también?
red888


2

Miré algunas formas diferentes, pero me gustó especialmente git-crypt para hacer algo ad hoc antes de implementar algo más grande como Vault.


2
a quienes votaron en contra, explique por qué.
jottr
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.