I’m just getting started with Terraform Cloud and remote execution mode. Following documentation, I need to add AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as environment variables to the workspace, which makes sense.
Normally (pre TF Cloud), we specify a role within the AWS provider to assume, that each person in our team has the right to assume - with their own personal ID/Key (set via env vars locally). How does this work with TF Cloud with multiple developers ? Must the workflow be changed to have only a single unique ID/Key per workspace that the provider uses ?
The intended model with Terraform Cloud is that each of your users has a separate Terraform Cloud account, and then you assign a single set of credentials to Terraform Cloud for each service a workspace depends on. That then avoids the need to issue credentials in a per-user-per-service matrix, and you can instead issue one Terraform Cloud credential to each user and one remote service credential per service.
Thanks for that. In hindsight, that is kind of obvious, but yes …not documented clearly, unless I missed something. Its an interesting model, but as we will have far more workspaces than users – I think it
increases the security attack surface, as we will now need many more sets of credentials that can assume a role that has full admin access.
Not sure if this is a best practice but my approach to this so far has been to:
Create a terraform IAM user. It has no privileges except to AssumeRole for roles specifically provisioned for configurations (workspaces).
Depending on your needs you could use the same Roles for multiple workspaces, but we’re trying to keep them minimally privileged.
Each workspace will assume_role for the role that has only the privileges needed for that configuration.
This minimizes what can be done and means the terraform IAM account itself has no privileges—not even to ListRoles. For these keys to be useful to anyone if lost, you’d also need to know the ARN of at least one role that it can assume.
Depending on your needs you could further divide into multiple TF IAM accounts if you need to isolate more.
We are using a separate terraform configuration to manage these roles themselves using terraform (you’ll need to manually bootstrap it though…chicken vs egg).
The last remaining piece is to automatically rotate access keys in TFC… this might be done using an on-prem process (e.g. Jenkins job) to run periodically to update all the workspaces with new keys on a regular basis through the TFC API or TFE provider. Haven’t really found a better solution for that.
Would love to see the possibility of TFC supporting cross account roles natively for AWS to avoid the access key situation.