Hi! I have a custom TF provider that implements a range of resources.
Currently these resources hardcode authn/z implementation in the package.
I want to refactor that out into my pipeline.
How do I specify a logical connection as to make these resources be able to look up secrets in Vault that are scoped to their corresponding resource types?
I guess what I’m asking is how to create a secret that can only be obtained by a certain Terraform resource type.
Hi @ror6ax,
What you’ve described is not possible. Terraform and all of the providers all run in the same security context, so they can’t effectively prevent each other from doing anything, and Vault has no way to prove which part of that whole stack is making a request so it can’t enforce that server-side either.
If I’ve understood correctly what your underlying goal is – obtaining credentials from vault to use to configure your provider – then a typical approach would be to use ephemeral resource types from the `hashicorp/vault provider to read the secrets, then refer to them in your own provider’s configuration block.
But security-wise your Vault permissions would either allow anything in the Terraform configuration to use that secret or nothing to use it, because there is no finer-grain security boundary to use to enforce the permissions more granularly than that.
@apparentlymart’s answer is correct in the sense that vault has no idea what resource is asking for a secret. Most of the time these secrets are first fetched through a data or ephemeral type via the vault provider, and the the values are used by (handed off to, if you will) a resource. The secret has already been fetched from vault by the time the TF resource goes to use it.
You can limit the scope of what secrets Terraform has access to through the use of vault policies. Terraform will have access to everything that the vault policy allows, but no more than that.
For even greater/stronger separation, you could give TF access to a separate secrets mount point that was only for TF’s usage. When the vault policy is constructed correctly, TF wouldn’t even be able to know that there were any other secrets mounts than the one it had access to. That could get a little messy, and the policies mentioned in the previous paragraph should be strong enough.
Could you point me to an example of this policy please?
The documentation is here:
but the basic idea is that an authenticated (IAM, approle, etc) user (or service account) get a role. The role they get has policies attached to it. Vault is deny-first, so the user can only get to things the policy explicitly allows.
The first example in the doc
path "secret/foo" {
capabilities = ["read"]
}
is also the simplest.
I would strongly suggest you invest time into understanding how vault works, how the different authentication methods work, and how policies work. These concepts are critical to operating a vault server/cluster in a secure manner.
If you’re already familiar with Terraform, the vault provider is available to help Terraform Registry