local_file should not prints sensitive information in the output if sensitive = true

[ghost]

This issue was originally opened by @mtheus as hashicorp/terraform#18718. It was migrated here as a result of the provider split. The original body of the issue is below.

---

Terraform Version

Terraform v0.11.8

Terraform Configuration Files

resource "local_file" "kubeconfig" {
    sensitive = true
    content  = "${data.terraform_remote_state.kubernetes.kubeconfig}"
    filename = ".kube/config"
}

Debug Output

Expected Behavior

Sensitive information does not seem to be in the output

Actual Behavior

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)

Steps to Reproduce

1. terraform init
2. terraform apply

Complementary

Should apply in all components that print outputs

[Lasering]

The code at master implements a solution: sensitve_content. Which is not consistent with the rest of terraform resources but at least its a solution.

However it seems its not yet available in Terraform v0.11.10 and provider.local v1.1.0.

[alewando]

This was implemented in #9 back in March 2018, but has not yet been released.

[mildwonkey]

@alewando sorry for the slow response here! The core team has been working heads-down on the terraform 0.12 release and unfortunately some things (like this provider!) have bene neglected as a result.

I will bookmark this to remind myself to go through the pending PRs and publish a release. Thanks for working on this particular issue, and thanks for your patience!

[joshmyers]

@mildwonkey Is there any chance of getting a release cut? We can fork and do a new release but it requires a load of boiler plate in Terraform orchestration to pull in a custom plugin.

[Sytten]

@mildwonkey Again, I call for a release. It's an easy win and could help us a lot.

[unacceptable]

@mildwonkey I also think that this would be a fantastic feature, and look forward to its release. 🙂

[Sytten]

For those looking for a temporary alternative, thats what I did to export credentials for multiple RDS databases (I have a map of database/password and a master password):

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
    }
  }
}

[invidian]

https://github.com/terraform-providers/terraform-provider-local/releases/tag/v1.2.0 is now out, which adds support for sensitive_content, so I think this issue can be now closed.

[mildwonkey]

thanks @invidian !

[ShahNewazKhan]

The local_file data source should also support sensitive_content

[unacceptable]

@ShahNewazKhan Are you saying that there should be an attribute sensitive_content for the local_file data source? If so, what would be a use case for this?

[diirib]

@unacceptable Imagine you're setting the content of the local_file resource via a different way than actually creating a local_file resource (or you just want to read an existing file). If that content is sensitive in the first place, you would need to access it without showing it directly in the output or in the tfstate.

[invidian]

I think having this functionality make sense. local_file data source could have sensitive_filename parameter, which would indicate, that the content should be put in sensitive_content property instead of the content (and content_base64). However, that seems like a new feature proposal. Perhaps we should create another issue to address it?

[diirib]

I just created it here:
#36

I believe the option should be present in the data structure, so it would be possible not only to get sensitive_content from files defined through local_file resources but also to get it from existing files.