feat: Use aws_service_principal data source for deriving IAM service prinicpals

[myerscf]

Using a Regions DNS Suffix is not an accurate way to determine the Service Principal Name for a service in different AWS Partitions.

This MR removes its use, in preference of the TF aws_service_principal resource, that will better determine the name and not cause deployment issues in Partitions.

[bryantbiggs]

Are you facing an issue

[myerscf]

Hi @bryantbiggs - yes, when trying to deploy into some AWS Partitions - using that Partitions domain to create the SPN, results in throwing an Invalid principal in policy validation error when deploying. Using the DNS suffix is an old, deprecated way of creating one.

aws_service_principal solves this, by creating the correct, backwards compatible SPN for a service, depending on which region you are deploying to :)

[bryantbiggs]

I'd like to learn more about this error you encountered, the error message, and what partition. the aws_service_principal data source is a relatively new source

[myerscf]

Sure!

So in some of the old AWS partitions, using the DNS suffix was accepted as part of the SPN, but this was quickly deprecated as more Partitions where created in favour of a standardised *.amazonaws.com. In the regions where it was first allowed, they will allow either - but all services where updated in favour of the standardised naming convention.

If you use the DNS suffix in the newer ones, where its not accepted you get an error like:

Error: creating IAM Role (<ROLE NAME>): operation error IAM: CreateRole, https response error StatusCode: 400,
RequestID: <REQUEST UUID>, MalformedPolicyDocument: Invalid principal in policy: "SERVICE":"ec2.c2s.ic.gov"

The aws_service_prinicipal resource was created, to match similar functionality in CDK - which allows users to create cross compatible SPNs in their policies, but enabling backwards compatibility for edge cases.
So for example if there is a region with an edge case say logs in the CN partition then it will return with the SPN with the DNS suffix - it not, the standardised one!

So, this change should keep things simple, and allow the modules to be easily deployed to different regions/partitions :D

[bryantbiggs]

thanks for the information, we use this pattern quite a bit so I wanted to understand better, and we've also encountered issues with partitions (mostly because services don't do a great job at defining when the partition/suffix should change)

[myerscf]

thanks for the information, we use this pattern quite a bit so I wanted to understand better, and we've also encountered issues with partitions (mostly because services don't do a great job at defining when the partition/suffix should change)

Updated to address the recommendations!

Will be happy to look through the other repos in terraform-aws-modules and PR similar changes to help with their use across AWS Partitions!

[myerscf]

Leaving the dns_suffix prop leaves us with a linting issue :( do you still want it left in?

Warning: [Fixable] local.dns_suffix is declared but not used (terraform_unused_declarations)