Scrub sensitive data in request/response logs

[radeksimko]

This will probably require further investigation (and possibly an RFC), but the high-level idea is that we could:

1. Redact any known sensitive headers from request/response logs, e.g. Authorization, X-Auth-*, X-*-Token
2. Known sensitive data (valid SSH/PGP private keys)
3. Values of fields from config (or computed) which are marked as sensitive
4. Introduce a way in the SDK for providers to mark certain values as sensitive (even if these aren't in the schema) - e.g. API returns 4 last digits of CC even though we don't expose it anywhere to the user

This is mainly about helper/logging which many providers already utilize today to log requests and responses:
https://github.com/hashicorp/terraform/tree/master/helper/logging

[paultyng]

Potentially related to work for #201 depending on if there is a more holistic approach to sensitive handling

FWIW I do think its valuable to get raw request/response though in trace/debug logs, so this may be more effort than its worth.

[paultyng]

There is now a system in core related to scrubbing sensitive values in stdout that will be part of 0.14: https://www.hashicorp.com/blog/announcing-hashicorp-terraform-0-14-beta

Configuration authors can now mark input variables as sensitive, and have those values redacted from the Terraform console output. This feature focuses on providing a tool for practitioners to help suppress the output of values from Terraform and infrastructure pipelines using Terraform, into systems that may not have the same controls, e.g. logging and /monitoring. Sensitive input variables provide a building block for protecting sensitive information.

For more specific sensitive handling enhancements, we should just open new specific issues.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

[paddycarver]

Reopening this as there was some confusion. The sensitive feature added to HCL in Terraform 0.14 does not filter any output to stderr or to logs and so is not an actual resolution to this issue.

Fundamentally, the issue at play here is that providers are writing values to stderr that they don't want written to stderr. This is a little bit on the SDK, for providing a logging transport that doesn't offer any controls for filtering, but provider developers can also just do the filtering themselves. The SDK is in a bit of an awkward position here, because it doesn't have the information the providers have about what fields it should consider sensitive, or what values to consider sensitive, and so would need to know about them to do any sort of filtering, realistically.

Ideally this would be solved by us providing options for providers to filter log output, and having the SDK own the filtering implementation and the provider just configure it, or Terraform core can also filter log output (all the log output goes through it, anyways) and could in theory use the Sensitive schema marker to filter values from logs, or could ask the user or provider to configure its log filters.

Fundamentally, I think this is blocked on the SDK team and the core team coming to a better understanding of the logging architecture we want to pursue in the future and the philosophy about who owns log output, Terraform or the providers.

[paddycarver]

#695 lays out another step in the direction of enabling this, and calls this out as a future direction. If people have input on that, we're definitely interested in hearing it.

[bflad]

There has been a lot of work to create the separate terraform-plugin-log Go module, which contains the tflog package usable by provider developers of both this SDK and the terraform-plugin-framework Go module. This log handling is the recommended logging solution for providers going forward over the Go standard library log package. Beyond the Go documentation, website documentation for writing logs via tflog can be found at: https://www.terraform.io/plugin/log/writing

Recent enhancements to the tflog package have added the ability to either omit whole log entries or mask portions of log messages/fields based on provider developer criteria, such as known string values or regular expressions. Beyond the Go documentation, website documentation for filtering logs via tflog can be found at: https://www.terraform.io/plugin/log/filtering

One starting caveat to using the tflog package with this SDK is that the provider code must be using the context-aware functionality of the SDK, where the SDK is giving provider logic a context.Context parameter. For example on the schema.Resource type, there are the context-aware fields such as ReadContext which must be used instead of the deprecated fields such as Read. All the tflog functionality is setup prior to reaching provider logic and passed through that context for each provider RPC.

Provider developers must ensure that any additional provider-defined configuration of the context, such as filtering, is done for each provider RPC. This means calls to the tflog.Mask*() and tflog.Omit*() functions must be performed before any logging calls are made within provider logic. If this configuration should be done for all managed resource operations, it should be at the top of the CreateContext/CreateWithoutTimeout, ReadContext/ReadWithoutTimeout, UpdateContext/UpdateWithoutTimeout, and DeleteContext/DeleteWithoutTimeout logic. Provider developers can simplify the logging configuration in cases like these by using typical Go code deduplication techniques, such as moving the logging configuration into its own separate function which returns the updated context.Context:

// Example log context configuration function. Other Go techniques can be used to
// deduplicate this logic as well, however this is shown to highlight the concept.
//
// This function could also handle advanced log configuration such as setting up
// additional log subsystems, etc. Pass the resource "meta" interface{} parameter
// (or its concrete type) to this function if provider-level data is needed.
func setupLogContext(ctx context.Context) context.Context {
  // Example update to the context to add log filtering
  ctx = tflog.MaskMessageStrings(ctx, "my-sensitive-value")

  return ctx
}

// Example usage in create, etc. functionality
func resourceExampleThingCreate(ctx context.Context, d *schema.ResourceData, meta interface{}) diag.Diagnostics {
  ctx = setupLogContext(ctx)
  // ... other creation logic ...
}

func resourceExampleThingRead(ctx context.Context, d *schema.ResourceData, meta interface{}) diag.Diagnostics {
  ctx = setupLogContext(ctx)
  // ... other read logic ...
}

SDK-based simplification of this type of "context configuration" logic can be discussed and tracked in the feature request: #858

One additional edge case for this type of functionality within this SDK is the currently undocumented http.Transport that is in the helper/logging package build on the Go standard library log package. Additional http.Transport functionality built on tflog is being handled as part of: #1006. This will be included in the next SDK release, version 2.20.0.

Since terraform-plugin-log functionality, once configured by provider developers, should cover this issue, I'm going to close it out. If there are specific bug reports or feature requests for the log filtering capabilities, please open an issue in the terraform-plugin-log issue tracker. If there are specific bug reports or feature requests with log configuration handling in this SDK, please open a new issue in the terraform-plugin-sdk issue tracker. If there are questions about provider logging or its configuration, please open a new topic in the Terraform Plugin SDK section of HashiCorp Discuss. Thanks.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.