This message was deleted.

I agree with storing all terraform state in one place, once it's spread out it becomes a mess keeping track of everything, and it's nice being able to define different accounts or logical domains via TF workspaces that are all centrally managed. We have many accounts as well, each of which handles a logical domain, like all DBs are in one account with nothing else, all DNS is in one account with nothing else, etc, and then we have one account that only handles IAM/users/etc. The way we handle permissions is via assuming roles. A base user has absolutely zero privileges, except the privilege of assuming certain roles in certain accounts. Our

<http://main.tf|main.tf>

file in our TF modules then all look a bit like the attached snippet. We create a provider for each role that the module will need to assume to perform its tasks. Each resource can then be assigned a specific provider. When a user executes TF apply, the apply only succeeds if the user has the permissions to assume the required role. Everything falls into place. In your situation, your bootstrapping process would involve having some sort of either manual or automated task that creates a role with the required permissions in the client's AWS account. These permissions would not only include the permissions to specific resources in the AWS account, but a trust relationship permission that would allow a role or user in your central account to assume that role. Then, in your central account, you allow a role or user to assume the role created in the client account. Now, your TF modules can specify a provider that points to the client's AWS account, and your TF user can be permissioned to assume the role in the client account. Let me know if you have any further questions happy to answer!

Hello @Alexandre Pauwels: Thanks for your response over here !! Let me try this approach and will come back to you !!

np let me know if you have any further questions 🙂