A wish: it would be great to have something similar for Terraform Cloud + Vault as we currently have with GitHub (Actions) and Vault - meaning, a proper possibility to authenticate against Vault truly credential-less.
To our understanding - as we are fortunate to use have Terraform Cloud for Business with agents (and we can run them in e.g. AWS), we’re able to let the agents authenticate into Vault using AWS IAM roles of the agent - but this unfortunately doesn’t provide a very granular (per workspace) access.
Or, does anyone have any other suggestions on how they have solved this? Anything with “use an approle” is out of window… There really shouldn’t be anything static flying around on this…
Now that there are products like HCP Vault and HCP Terraform - this tight integration between the products would be very important.
There always needs to be something to hang off of, which could be some form of secret or trusting another system to give details of what is allowed.
For AWS that mechanism is IAM, with the ability to attach a IAM role (or use an IAM user, which needs secret values) to things like an EC2 instance or EKS pod. So if you want to have two different set of permissions, you have two options:
Have separate EC2 instances/pods/lambdas for each one
Accept having just one instance that has both sets of permissions
That’s the thing: there are not just two different sets of permissions, there are… Maybe even 8. So, using different agent pools with different AWS IAM roles is just a waste.
It would be pretty cool if agent runs would have their own OIDC token (like GitHub actions). So, you could add TFC agent OIDC as a provider to Vault and permit agent runs probably on TFC workspace level to Vault secrets.
That would be an integrated secretless experience for Hashicorp products!
I wouldn’t call it secretless, as that OIDC token is a secret, but yes if TFC passed in a secret that’s based on the run you could be more granular. We do something similar for our Jenkins based system - the Jenkins run passes in a Vault token which is tied to the specific job/instance.
Yes and no … I understand the Vault token in your Jenkins use-case as something you really need to store inside Jenkins.
The OIDC token approach as I imagine it wouldn’t be stored somewhere statically as it would be generated every time a TFC agent would start a run - like GHA About security hardening with OpenID Connect - GitHub Docs
Yeah, that was the idea of this discussion thread. We’ll point our CSM to this thread also.
Iiro and me were just thinking that Hashicorp people will be also here in this forum and join the discussion - maybe it is already on some roadmap.
This community forum is primarily here for those who are using the open source products and so the HashiCorp employees that are here (which includes me) are more often folks who work on the open source components rather than on Terraform Cloud.
While I’m sure someone who works on Terraform Cloud will see this eventually, the most expedient way to send feedback about Terraform Cloud is via HashiCorp Support.
Sure. Also, @jgrumboe and I were mostly / also hoping there would be other TFCB customers here - as everyone with a Vault actually has the same problem. To my understanding, this is also the best forum to communicate with other Hashicorp customers as well. Or maybe I’m mistaken…
Right now, AFAIK, the “state of the art” is “use an AppRole” - with automation to frequently generate new SecretIDs, and push them into the TFC API as sensitive variables, letting the old SecretIDs expire.
I think we’ll architect some compromise now using the TFC agent pools to a bit segregation (and I guess log into Vault with the AWS auth using IAM - at least for now) - and continue the investigations behind the scenes how to replace this in long run. AppRoles are not very tempting…
Indeed! There’s certainly nothing wrong with using this forum to discuss with other Terraform Cloud customers, particularly if you’re talking about different ways to use features that already exist.
I just wanted to be explicit that the Terraform Cloud teams primarily consume feedback from the customer support team and account managers rather than this forum, and so once the discussion shifts from using what’s already implemented to requesting new features then that’s a good time to switch to contacting the support team or, where appropriate, talking directly with your CSM. Thanks!
