_Este problema lo abrió originalmente @mtheus como hashicorp/terraform#18718. Se migró aquí como resultado de la división del proveedor . El cuerpo original del problema se encuentra a continuación._
Terraform v0.11.8
resource "local_file" "kubeconfig" {
sensitive = true
content = "${data.terraform_remote_state.kubernetes.kubeconfig}"
filename = ".kube/config"
}
La información confidencial no parece estar en la salida
data.terraform_remote_state.kubernetes: Refreshing state...
local_file.kubeconfig: Creating...
content: "" => "\n\napiVersion: v1\nclusters:\n- cluster:\n server: https://**<SENSIVE>**.sk1.us-east-1.eks.amazonaws.com\n certificate-authority-data: LS0tLS1C**<SENSIVE>**\n name: kubernetes\ncontexts:\n- context:\n cluster: kubernetes\n user: aws\n name: aws\ncurrent-context: aws\nkind: Config\npreferences: {}\nusers:\n- name: aws\n user:\n exec:\n apiVersion: client.authentication.k8s.io/v1alpha1\n command: aws-iam-authenticator\n args:\n - \"token\"\n - \"-i\"\n - \"latam\"\n"
filename: "" => ".kube/config"
local_file.kubeconfig: Creation complete after 0s (ID: 73a74cc24de6ebfe8304a9b889415884fd819390)
terraform init
terraform apply
Debe aplicarse en todos los componentes que imprimen salidas
El código del maestro implementa una solución: sensitve_content
. Lo cual no es consistente con el resto de recursos de terraform pero al menos es una solución.
Sin embargo, parece que aún no está disponible en Terraform v0.11.10 y provider.local v1.1.0.
Esto se implementó en el n.º 9 en marzo de 2018, pero aún no se ha publicado.
@alewando perdón por la respuesta lenta aquí! El equipo central ha estado trabajando de cabeza en el lanzamiento de terraform 0.12 y, lamentablemente, algunas cosas (¡como este proveedor!) se han descuidado como resultado.
Marcaré esto como favorito para recordarme revisar los PR pendientes y publicar un comunicado. ¡Gracias por trabajar en este tema en particular, y gracias por su paciencia!
@mildwonkey ¿Hay alguna posibilidad de obtener un corte de lanzamiento? Podemos bifurcarnos y hacer una nueva versión, pero requiere una gran cantidad de placa de caldera en la orquestación de Terraform para obtener un complemento personalizado.
@mildwonkey Nuevamente, pido una liberación. Es una victoria fácil y podría ayudarnos mucho.
@mildwonkey También creo que esta sería una característica fantástica y espero su lanzamiento. 🙂
Para aquellos que buscan una alternativa temporal, eso es lo que hice para exportar credenciales para múltiples bases de datos RDS (tengo un mapa de base de datos/contraseña y una contraseña maestra):
locals {
databases = "${keys(var.shared_db_databases_passwords)}"
manual_output = {
endpoint = "${module.shared_database.database_endpoint}"
username = "myusername"
password = "${var.shared_db_master_password}"
port = 5432
databases = "${local.databases}"
passwords = "${values(var.shared_db_databases_passwords)}"
}
}
resource "null_resource" "manual_output" {
triggers {
databases = "${join(",", local.databases)}"
}
provisioner "local-exec" {
command = "echo $DATA > manual_output.json"
environment {
DATA = "${jsonencode(local.manual_output)}" # Necessary to hide outputs
}
}
}
https://github.com/terraform-providers/terraform-provider-local/releases/tag/v1.2.0 ya está disponible, lo que agrega soporte para sensitive_content
, por lo que creo que este problema se puede cerrar ahora.
gracias @invidian !
La fuente de datos local_file
también debería ser compatible sensitive_content
@ShahNewazKhan ¿Está diciendo que debería haber un atributo sensitive_content
para la fuente de datos local_file
? Si es así, ¿cuál sería un caso de uso para esto?
@inacceptable Imagine que está configurando el contenido del recurso local_file de una manera diferente a la creación real de un recurso local_file (o simplemente desea leer un archivo existente). Si ese contenido es confidencial en primer lugar, deberá acceder a él sin mostrarlo directamente en la salida o en el tfstate.
Creo que tener esta funcionalidad tiene sentido. La fuente de datos local_file
podría tener el parámetro sensitive_filename
, lo que indicaría que el contenido debe colocarse en la propiedad sensitive_content
en lugar de la propiedad content
(y content_base64
). Sin embargo, parece una nueva propuesta de función. ¿Quizás deberíamos crear otro problema para abordarlo?
Lo acabo de crear aquí:
https://github.com/terraform-providers/terraform-provider-local/issues/36
Creo que la opción debería estar presente en la estructura de datos, por lo que sería posible no solo obtener contenido sensible de archivos definidos a través de recursos de archivo local, sino también obtenerlo de archivos existentes.
Comentario más útil
https://github.com/terraform-providers/terraform-provider-local/releases/tag/v1.2.0 ya está disponible, lo que agrega soporte para
sensitive_content
, por lo que creo que este problema se puede cerrar ahora.