Implement awscc_sts_caller_identity

[mattburgess]

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

A number of resources require access to the current account ID, arn or user ID, e.g. when constructing KMS key policies. In the aws provider these are available via the aws_caller_identity datasource, but there doesn't appear to be an equivalent in the awscc provider. Having a native awscc datasource would be beneficial to avoid having to use both providers.

New or Affected Resource(s)

• datasource/awscc_sts_caller_identity (for closer alignment to the AWS API) OR
• datasource/awscc_caller_identity (for closer alignment with the aws provider)

Potential Terraform Configuration

data "awscc_sts_caller_identity" "current" {}

output "account_id" {
  value = data.awscc_sts_caller_identity.current.account_id
}

output "caller_arn" {
  value = data.awscc_sts_caller_identity.current.arn
}

output "caller_user" {
  value = data.awscc_sts_caller_identity.current.user_id
}

References

• #0000

[mattburgess]

I note that STS doesn't have any resources listed as supporting the CloudControl API so this likely isn't going to be possible to autogenerate in the near term. Is there precedent anywhere in the provider for having hand-rolled support? I'm wondering whether the datasource could be more or less lifted and shifted from the aws provider for the time being?

[breathingdust]

Relates #729

Hi @mattburgess! So far our approach is to not attempt to duplicate these types of resources between the providers, and encourage the dual provider pattern. We would be open to revising this position provided we see enough community demand for it.

[mattburgess]

Ah, thanks for the pointer to the other issue, my github search fu wasn't strong enough to find it. I'm happy for this one to be closed as a duplicate of that one if you'd like?