Optionally specify additional user agent details using ProviderMeta

[drewmullen]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment
• The resources and data sources in this provider are generated from the CloudFormation schema, so they can only support the actions that the underlying schema supports. For this reason submitted bugs should be limited to defects in the generation and runtime code of the provider. Customizing behavior of the resource, or noting a gap in behavior are not valid bugs and should be submitted as enhancements to AWS via the CloudFormation Open Coverage Roadmap.

Description

Enable Terraform configuration authors to optionally specify additional user-agent data that terraform passes on to AWS Cloud Control API's.

This is useful for discovery and compliance purposes, as the user-agent for each API call is available as a CloudTrail event. Teams can use this data to identify workloads running in their account such as 3rd party products, OU's, etc.

Question: should we replace #247 with this feature?

New or Affected Resource(s)

• Include ProviderMeta for awscc provider

Potential Terraform Configuration

terraform {
  required_version = ">= 0.15.3"
  required_providers {
    awscc = {
      source = "hashicorp/awscc"
      version = "= 0.19.0"
    }
  }
  provider_meta "awscc" {
    user_agent = [{
      name    = "my-test-module"
      version = "0.0.1"
      comment = "testing user-agent comment" 
    }]
  }
}

References

• #247
• https://github.com/hashicorp/terraform-provider-awscc/issues/466#issuecomment-1099174159

[gdavison]

I think we should leave #247, i.e., the ability to specify user-agent components at the provider level. The two features serve slightly different purposes. At the provider level, it means everything that this provider touches in the whole configuration including modules, whereas this feature is scoped to the specific module.

We'll want to make this clear in the documentation.