Terraform-provider-local: local_file ne doit pas imprimer d'informations sensibles dans la sortie si sensitive = true

Le code de master implémente une solution : sensitve_content . Ce qui n'est pas cohérent avec le reste des ressources de terraform mais au moins c'est une solution.

Cependant, il semble qu'il ne soit pas encore disponible dans Terraform v0.11.10 et provider.local v1.1.0.

Cela a été implémenté dans # 9 en mars 2018, mais n'a pas encore été publié.

@alewando désolé pour la lenteur de la réponse ici ! L'équipe principale a travaillé d'arrache-pied sur la version 0.12 de Terraform et, malheureusement, certaines choses (comme ce fournisseur !) ont été négligées en conséquence.

Je mettrai ceci en signet pour me rappeler de parcourir les relations publiques en attente et de publier un communiqué. Merci de travailler sur ce problème particulier, et merci pour votre patience !

@mildwonkey Y a-t-il une chance d'obtenir une version coupée? Nous pouvons bifurquer et faire une nouvelle version, mais cela nécessite une charge de chaudière dans l'orchestration Terraform pour extraire un plugin personnalisé.

@mildwonkey Encore une fois, j'appelle à une libération. C'est une victoire facile et cela pourrait nous aider beaucoup.

@mildwonkey Je pense aussi que ce serait une fonctionnalité fantastique et j'attends avec impatience sa sortie. 🙂

Pour ceux qui recherchent une alternative temporaire, c'est ce que j'ai fait pour exporter les informations d'identification de plusieurs bases de données RDS (j'ai une carte de base de données/mot de passe et un mot de passe principal):

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 est maintenant disponible, ce qui ajoute la prise en charge de sensitive_content , donc je pense que ce problème peut maintenant être clos.

merci @invidian !

La source de données local_file doit également prendre en charge sensitive_content

@ShahNewazKhan Êtes-vous en train de dire qu'il devrait y avoir un attribut sensitive_content pour la source de données local_file ? Si oui, quel serait un cas d'utilisation pour cela?

@inacceptable Imaginez que vous définissiez le contenu de la ressource local_file d'une manière différente de la création réelle d'une ressource local_file (ou que vous vouliez simplement lire un fichier existant). Si ce contenu est sensible en premier lieu, vous devrez y accéder sans l'afficher directement dans la sortie ou dans le tfstate.

Je pense que cette fonctionnalité a du sens. La source de données local_file pourrait avoir le paramètre sensitive_filename , ce qui indiquerait que le contenu doit être placé dans la propriété sensitive_content au lieu de content (et content_base64 ). Cependant, cela semble être une nouvelle proposition de fonctionnalité. Peut-être devrions-nous créer un autre problème pour y remédier ?

Je viens de le créer ici :
https://github.com/terraform-providers/terraform-provider-local/issues/36

Je pense que l'option devrait être présente dans la structure de données, de sorte qu'il serait possible non seulement d'obtenir sensitive_content à partir de fichiers définis via des ressources local_file, mais également de l'obtenir à partir de fichiers existants.