As I start to workload identity tokens, the security aspects of them are a bit interesting. It’d really be more secure if they were generated per-provider such that there was a claim specifying the target provider and it was only provided to that one provider so that a compromised provider couldn’t grab the single workspace-wide token and authenticate to any other providers that happened to be used in the workspace and using identity tokens.
Guess the claim I’m referring to should really just be the audience claim, so effectively the TFC_WORKLOAD_IDENTITY_AUDIENCE variable would be customizable per-provider somehow.
This is an interesting topic.
Would you mind further contextualizing it for those of us less familiar with what’s going on?
I think that the terraform executable starts the provider executables, and they communicate via mTLS via a local socket file.
I also think that the socket file is created by the provider, making the provider the listener/server in the transaction.
So far so good?
I’m curious to learn more about both the mTLS trust relationships (how many certificates involved, and who trusts what?) and the tokens (which I didn’t previously know about, but I suspect that TLS enthusiasts will be happy to know that session encryption/authN/authZ aren’t all lumped together into the mTLS bucket).
I think the scenario you’re thinking about looks like:
- Terraform launches victim provider
- Terraform gives victim provider API credentials
- Terraform launches evil provider
- Evil provider is able to talk to victim provider due to mTLS and/or token abuse which could be mitigated.
- Evil provider directs victim provider to do something unfortunate using credentials known only to terraform and victim provider
Is that about right?