_Diese Ausgabe wurde ursprünglich von @mtheus als hashicorp/terraform#18718 geöffnet. Aufgrund der Anbieteraufspaltung wurde es hierher migriert. Der Originaltext der Ausgabe ist unten._
Terraform v0.11.8
resource "local_file" "kubeconfig" {
sensitive = true
content = "${data.terraform_remote_state.kubernetes.kubeconfig}"
filename = ".kube/config"
}
Sensible Informationen scheinen nicht in der Ausgabe zu sein
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
Sollte in allen Komponenten gelten, die Ausgaben drucken
Der Code bei master implementiert eine Lösung: sensitve_content
. Was nicht mit den restlichen Terraform-Ressourcen übereinstimmt, aber zumindest eine Lösung ist.
Es scheint jedoch noch nicht in Terraform v0.11.10 und provider.local v1.1.0 verfügbar zu sein.
Dies wurde bereits im März 2018 in #9 implementiert, aber noch nicht veröffentlicht.
@alewando Entschuldigung für die langsame Antwort hier! Das Kernteam hat mit Hochdruck an der Veröffentlichung von Terraform 0.12 gearbeitet, und leider wurden einige Dinge (wie dieser Anbieter!) dadurch vernachlässigt.
Ich werde dies mit einem Lesezeichen versehen, um mich daran zu erinnern, die ausstehenden PRs durchzugehen und eine Veröffentlichung zu veröffentlichen. Vielen Dank, dass Sie an diesem speziellen Problem arbeiten, und danke für Ihre Geduld!
@mildwonkey Gibt es eine Chance auf einen Release Cut? Wir können forken und eine neue Version erstellen, aber es erfordert eine Menge Boiler Plate in der Terraform-Orchestrierung, um ein benutzerdefiniertes Plugin einzufügen.
@mildwonkey Wieder fordere ich eine Freilassung. Es ist ein einfacher Sieg und könnte uns sehr helfen.
@mildwonkey Ich denke auch, dass dies ein fantastisches Feature wäre, und freue mich auf seine Veröffentlichung. 🙂
Für diejenigen, die nach einer vorübergehenden Alternative suchen, habe ich das getan, um Anmeldeinformationen für mehrere RDS-Datenbanken zu exportieren (ich habe eine Karte von Datenbank/Passwort und ein Master-Passwort):
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 ist jetzt verfügbar, was Unterstützung für sensitive_content
hinzufügt, daher denke ich, dass dieses Problem jetzt geschlossen werden kann.
danke @invidian !
Die Datenquelle local_file
sollte auch sensitive_content
unterstützen
@ShahNewazKhan Wollen Sie damit sagen, dass es ein Attribut sensitive_content
für die Datenquelle local_file
geben sollte? Wenn ja, was wäre ein Anwendungsfall dafür?
@unacceptable Stellen Sie sich vor, Sie legen den Inhalt der local_file-Ressource auf eine andere Weise fest, als tatsächlich eine local_file-Ressource zu erstellen (oder Sie möchten nur eine vorhandene Datei lesen). Wenn dieser Inhalt überhaupt vertraulich ist, müssten Sie darauf zugreifen, ohne ihn direkt in der Ausgabe oder im tfstate anzuzeigen.
Diese Funktion halte ich für sinnvoll. Die Datenquelle local_file
könnte den Parameter sensitive_filename
haben, der angeben würde, dass der Inhalt in die Eigenschaft sensitive_content
anstatt in die Eigenschaft content
(und content_base64
). Das scheint jedoch ein neuer Funktionsvorschlag zu sein. Vielleicht sollten wir ein anderes Problem erstellen, um es anzugehen?
Ich habe es gerade hier erstellt:
https://github.com/terraform-providers/terraform-provider-local/issues/36
Ich glaube, die Option sollte in der Datenstruktur vorhanden sein, sodass es möglich wäre, sensitive_content nicht nur aus Dateien zu erhalten, die durch local_file-Ressourcen definiert sind, sondern auch aus vorhandenen Dateien.
Hilfreichster Kommentar
https://github.com/terraform-providers/terraform-provider-local/releases/tag/v1.2.0 ist jetzt verfügbar, was Unterstützung für
sensitive_content
hinzufügt, daher denke ich, dass dieses Problem jetzt geschlossen werden kann.