Leaking Private-Token in debug logs

How to prevent private tokens from leaking in debug logs?

It is too easy to share the log while looking for help.

2020-06-22T12:44:35.781+0300 [DEBUG] plugin.terraform-provider-gitlab: 2020/06/22 12:44:35 [DEBUG] GitLab API Request Details:
2020-06-22T12:44:35.781+0300 [DEBUG] plugin.terraform-provider-gitlab: ---[ REQUEST ]---------------------------------------
2020-06-22T12:44:35.782+0300 [DEBUG] plugin.terraform-provider-gitlab: GET /api/v4/user HTTP/1.1
2020-06-22T12:44:35.782+0300 [DEBUG] plugin.terraform-provider-gitlab: Host: gitlab.com
2020-06-22T12:44:35.782+0300 [DEBUG] plugin.terraform-provider-gitlab: User-Agent: go-gitlab
2020-06-22T12:44:35.782+0300 [DEBUG] plugin.terraform-provider-gitlab: Accept: application/json
2020-06-22T12:44:35.782+0300 [DEBUG] plugin.terraform-provider-gitlab: Private-Token: **DON'T WANT TO SEE THIS**
2020-06-22T12:44:35.782+0300 [DEBUG] plugin.terraform-provider-gitlab: Accept-Encoding: gzip
2020-06-22T12:44:35.782+0300 [DEBUG] plugin.terraform-provider-gitlab:

Hi @abitrolly,

There’s currently no good way to do this. In theory, it could be done using a scrubbing tool, but that’s not the most satisfying answer. Issue #2 on the SDK is tracking this.

0.14 adds sensitive = true for this purpose.

variable "user_information" {
  type = object({
    name    = string
    address = string
  })
  sensitive = true
}

While that’s true, I believe that the way that sensitive marker is implemented doesn’t pass the information on to providers, unfortunately.

Fundamentally, the trouble is that we need to know what specific text to replace, and need to filter it on the fly from logs. And so Terraform or the provider would need to be told that a particular value is sensitive and shouldn’t show up anywhere in logs. Terraform could do that, using sensitive, but it would require a change to the Terraform Core logging subsystem, and this isn’t really the place for that conversation–the Terraform forum or the Terraform issue tracker are probably the right place to discuss that. Alternatively, the provider itself could choose not to log that header. The SDK, unfortunately has no good levers I can see to pull that will help with this. The SDK doesn’t have access to the information that the data is sensitive, like core does, and it doesn’t have the domain-specific knowledge to know that certain parts of logs are sensitive, like the provider does. It’s in the awkward middle.

Terraform could do that, using sensitive , but it would require a change to the Terraform Core logging subsystem, and this isn’t really the place for that conversation–the Terraform forum or the Terraform issue tracker are probably the right place to discuss that.

I am confused. Isn’t this place the Terraform forum? Tracker issue Scrub sensitive data in request/response logs · Issue #2 · hashicorp/terraform-plugin-sdk · GitHub is also closed. Nowhere to run. :smiley:

Ack! I may just be flat-out wrong here. This is what I get for replying without checking in with the core team first.

This forum is for provider development using the Plugin SDK. This is the Terraform forum category about Terraform core.

Do you mean that it is impossible to mark variables as sensitive inside Provider? That this option is only for users writing .tf scripts?

That is my belief at the moment, yes. I’ve tracked down some more information and reopened issue 2, it turns out there was some confusion there about what that feature meant. Apologies. :frowning:

My current understanding, after a chat with the core folks, is that the new sensitive behavior is just extending to current users the abilities extended to provider developers, to mark data as sensitive and keep it from showing up in plans and other terraform command outputs, but that it doesn’t do any log filtering. (“Log” gets a bit overloaded here, because Terraform Cloud customers often consider the output of the terraform command as “logs”, and not the output to stderr when TF_LOG is set.) It’s also, For Reasons, not visible to providers at this time, as far as I know.

[edit] Sorry, to be clear: providers can still mark fields as sensitive, the same way they have for years, but marking variables as sensitive inside a provider isn’t a thing (as providers have no concept of variables, as far as I know).

When providers write logs, there may be sensitive data which should not be present in log messages or structured log fields. The tflog package supports masking data or omitting log entries entirely before they are output via the provider root logger or provider-defined subsystem loggers. For more info, refer this URL below,