Allow for selection of Terraform Cloud project ID other than 'Default Project'

[rybons]

Describe the outcome you'd like

I would like to be able to manage my AFT workspaces in a Terraform Cloud project other than Default Project.

Is your feature request related to a problem you are currently experiencing? If so, please describe.

The module does not seem to support a variable where I can specify a project_id to ensure the workspaces managed by AFT get created under a particular Terraform Cloud project of my choosing.

This would be a nice feature because If the Default Project space is used for other (non-AFT) purposes, existing workspaces can get drowned out and hard to find once AFT starts creating a lot of customizations workspaces.

Additional context

Based on my understanding of the AFT workflow, it may make sense to:

• Store the TFC project_id as an SSM parameter (sourced from an option module variable input - which could hopefully default to null).
• Retrieve the parameter in workspace_manager.py.
• Add support for data.relationships.project.data.id in the create workspace request body.

See:

• https://www.hashicorp.com/blog/terraform-cloud-adds-projects-to-organize-workspaces-at-scale
• https://developer.hashicorp.com/terraform/cloud-docs/api-docs/workspaces

Other considerations

Assume AFT workspaces are already being created/used in Default Project. If this feature were to be added, will AFT simply correct the course? Or, would the AFT user need to perform any sort of migration to transition any pre-existing AFT workspaces to a different project?

[wellsiau-aws]

Do you see value of specifying the project as part of account request? so that admins can manage workspaces by group of projects and perhaps use it to drive other things (i.e. variable sets)

[rybons]

@wellsiau-aws In my case I am primarily using AFT for its global-customizations feature as a means of being able to deploy baseline (usually compliance-related) resources to all of my accounts.

For now, I have chosen to keep terraform code related to my actual application-related infrastructure outside of the AFT workflow (i.e. I'm not using account-customizations for anything meaningful at the moment). So from my personal use-case/perspective, AFT's relationship with TFC workspaces is quite simple. I just need a separate TFC project space to manage all of my customizations workspaces.

I suppose from your perspective you need to consider that account-customizations might be set for application-A, application-B and application-C and that end-users may wish to manage account-customizations-related workspaces in separate TFC project folders (mapped to each application).

So to answer your question directly:

No, I don't see value in that for my use case. However, I think thats largely because of how I'm making use of AFT. If I were making more use of account-customizations, I could see why the account request section of the workflow might make more sense as the place where project_id is defined.

---

drive other things (i.e. variable sets)

One other interesting pattern I'm exploring in terms of the relationship between a TFC workspace and an AWS account is the authentication piece.

I notice today that you guys use workspace variables with session credentials to allow the workspace to apply customizations (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_SESSION_TOKEN).

I wonder if you may be able to create a more permanent (but still session-driven) relationship between the customizations TFC workspaces and the AWS account by making use of an IAM OIDC provider. This has recently been supported by TFC.

To expand on your mention of variable sets... It would be interesting if accounts that were shipped via aft-account-requests also came with accompanying OIDC-based variable sets in TFC (TFC_AWS_RUN_ROLE_ARN, TFC_AWS_PROVIDER_AUTH, and AWS_REGION).

This would allow for an easy way to "make the connection" between a TFC workspace and an AFT-provisioned account (whether that workspace that eventually makes use of the variable set is generated/associated with AFT or not).

[wellsiau-aws]

Thanks for sharing your perspective, this is very useful!

regarding dynamic provider crednetials / OIDC-based variable, we have open request about it (#318)

[rybons]

Thanks for sharing your perspective, this is very useful!

regarding dynamic provider crednetials / OIDC-based variable, we have open request about it (#318)

No problem. Good to see you're looking at OIDC providers!

[snebhu3]

@rybons thank you for reaching out. I have created a backlog to explore this feature request.

[robbycuenot]

+1 on this idea. I would like to make use of project-scoped permissions in TFC, but manually moving new workspaces into the project is clunky. Adding this feature would be awesome

[robbycuenot]

My workaround for the time being is to rename the default project and leverage it just for AFT