Tfc_ouptputs vs terraform_remote_state

Terraform HCP Terraform
1

Hi, everyone!

I recently noticed that using the data source terraform_remote_state is not advised if I want to share some outputs between workspaces (source). Instead, I should use the tfe_outputs data source. However, the “Important” note says:

The tfe_outputs data source is more secure because it does not require full access to workspace state to fetch outputs.

But does it mean I don’t need to explicitly allow workspace B to access the state of workspace A to share the outputs? (from the remote_state_consumer_ids), or should I keep the configuration?

Also, because the tfe_outputs comes from the tfe provider, do I need to provide Terraform Cloud credentials to the workspace? Like a TFE_TOKEN that would have read access to the workspace that exposes the outputs?

Thank you!

Cheers,
Antoine Rouaze

2

I found the answers by doing some tests.

But does it mean I don’t need to explicitly allow workspace B to access the state of workspace A to share the outputs? (from the remote_state_consumer_ids), or should I keep the configuration?

No need to explicitly set the dependencies between the workspaces; it works without them. However, I wonder if the configuration Remote state sharing is not useless now with this data source?

Also, because the tfe_outputs comes from the tfe provider, do I need to provide Terraform Cloud credentials to the workspace? Like a TFE_TOKEN that would have read access to the workspace that exposes the outputs?

It doesn’t appear that I need any credentials to access outputs of workspace A from workspace B.

Cheers,
Antoine Rouaze

3

Hi @Erouan50,

I must admit that I’m not an expert on these features either and so perhaps one of my colleagues who works on Terraform Cloud will correct me or say more, but:

When Terraform Cloud runs Terraform Core in its remote execution environment, it automatically issues that process a short-lived Terraform Cloud API token which the provider can then make use of without any explicit configuration.

Those temporary tokens will have less access than one issued to a normal user account, but the “remote state sharing” mechanism you mentioned does involve giving that token some additional access so it can retrieve the state.

4

:wave:t2: Howdy, colleague here :smiley:

But does it mean I don’t need to explicitly allow workspace B to access the state of workspace A to share the outputs? (from the remote_state_consumer_ids)

You don’t need remote state consumer access, no. The remote state consumer feature is to specifically control the implicit read access to all an organization’s states that the terraform_remote_state data source utilizes (via the short-lived API token that Martin mentions).

Using the tfe_outputs via the TFE provider is more secure as you provide your own API token with explicit permissioned access (including the ‘outputs only’ permission, which only allows access to outputs and not the whole state file) to the state/outputs of a given workspace. Which brings me to this part…

It doesn’t appear that I need any credentials to access outputs of workspace A from workspace B.

You should absolutely need to have an authorized token set to access a workspace’s outputs, though note that the token you’re using may have access by virtue of being an user token of an owner, someone with “Manage Workspaces” permission, etc. For more on how permissions work, see the documentation here.

5

Hi @apparentlymart and @chrisarcand,

Thank you for your answers!

@apparentlymart I didn’t know that Terraform Cloud would provide a short-lived token, but it makes sense otherwise the workspace wouldn’t be able to download the private modules, providers, etc…

@chrisarcand I have some comments from your answer :slight_smile::

You don’t need remote state consumer access, no. The remote state consumer feature is to specifically control the implicit read access to all an organization’s states that the terraform_remote_state data source utilizes (via the short-lived API token that Martin mentions).

Ok, that makes total sense :+1:

You should absolutely need to have an authorized token set to access a workspace’s outputs, though note that the token you’re using may have access by virtue of being an user token of an owner, someone with “Manage Workspaces” permission, etc. For more on how permissions work, see the documentation here.

I did some tests, and I can create a workspace A that exposes an output that a workspace B can access without any TFC token in the workspace configuration (like a TFE_TOKEN variable). During my tests, I used only the mode remote, but I agree that my current TFC token would give me access to the outputs with the local mode.

I created a gist with my test infra if you want to try to reproduce my tests: tfc_ouptputs vs terraform_remote_state · GitHub. If you execute it, you’ll notice that in workspace B, the null resource can display the output from workspace A without any custom TFE_TOKEN configured on the workspace. However, if I set the output from workspace A as sensitive, I run into this issue: Sensitive values is missing · Issue #449 · hashicorp/terraform-provider-tfe · GitHub (with or without the TFE_TOKEN configured on workspace B).

Thank again for your help!

6

So, this does highlight a deficiency in the permissions model.

  1. Sharing remote state from “Workspace A” to “Workspace B” grants permissions to the run token for “Workspace B” to access the state, including the outputs. Without this setting, the run token will in no way have access to the outputs.
  2. Creating a token and granting the team or user “Read outputs only” on State Access resolves this concern, but now a long-lived token with all the requisite concerns is created.

It would be a good feature to allow for an “outputs only” flag when setting “Remote state sharing”. This would resolve these concerns and allow for a low-friction way to adhere to a best practice.