How to output attributes of resources created? - google-cloud-platform

Question

I'm executing a GCP module to create a service account.
main.tf:
resource "google_service_account" "gsvc_account" {
account_id = "xxx"
display_name = ""
project = "proj-yyy"
}
output "account_id" {
value = "${google_service_account.gsvc_account.account_id}"
}
Once the account is created, a terraform.tfstate file is created containing all details of the account.
terraform.tfstate
{
"version": 4,
"terraform_version": "0.12.0",
"serial": 3,
"lineage": "aaaa-bbbb-cccc",
"outputs": {
"xxx": {
"value": "xxx",
"type": "string"
}
},
"resources": [
{
"module": "module.gsvc_tf",
"mode": "managed",
"type": "google_service_account",
"name": "gsvc_account",
"provider": "provider.google",
"instances": [
{
"schema_version": 0,
"attributes": {
"account_id": "xxx",
"display_name": "",
"email": "xxx#yyy.com",
"id": "projects/proj-yyy/serviceAccounts/xxx#yyy.com",
"name": "projects/proj-yyy/serviceAccounts/xxx#yyy.com",
"policy_data": null,
"project": "proj-xxx",
"unique_id": "10891885"
}
}
]
}
]
}
As you can see above, in the module, I'm outputing the account_id input variable. Is there a way to output the attributes viz. id, name etc. so that they can be accessed by another module? The attributes are computed after the resource is created.

Answer 1

From the docs for the google_service_account resource:
the following computed attributes are exported:
email - The e-mail address of the service account. This value should be referenced from any google_iam_policy data sources that would grant the service account privileges.
name - The fully-qualified name of the service account.
unique_id - The unique id of the service account.
You can declare outputs using these attributes in the same way as you declared your account_id output. For example:
output "id" {
value = "${google_service_account.gsvc_account.unique_id}"
}
output "email" {
value = "${google_service_account.gsvc_account.email}"
}
Re this: "so that they can be accessed by another module" ... if the "other module" uses the same state file then the above outputs are addressable using ...
${google_service_account.gsvc_account.account_id}
${google_service_account.gsvc_account.email}
etc
... i.e. you don't need outputs at all. So, I'm guessing that the "other module" is in a separate project / workspace / repo and hence is using a different state file. If so, then you would access these outputs via remote state. For example, you would declare a remote state data source to point at whatever state contains your outputs:
resource "terraform_remote_state" "the_other_state" {
backend = "..."
config {
...
}
}
And then refer to the outputs within that state like so:
${terraform_remote_state.the_other_state.output.account_id}
${terraform_remote_state.the_other_state.output.email}
etc

Answer 2

If your other module is ran against a different state file (eg your Terraform code is in a separate directory) then you might be better off using the google_service_account data source instead of trying to output the values of the resource to your state file and using the terraform_remote_state data source to fetch them.
The documentation for the google_service_account data source shows a nice example of how you would use this:
data "google_service_account" "myaccount" {
account_id = "myaccount-id"
}
resource "google_service_account_key" "mykey" {
service_account_id = "${data.google_service_account.myaccount.name}"
}
resource "kubernetes_secret" "google-application-credentials" {
metadata = {
name = "google-application-credentials"
}
data {
credentials.json = "${base64decode(google_service_account_key.mykey.private_key)}"
}
}
This avoids needing to configure your remote state data source and can be significantly simpler. In fact, this is the way I'd recommend accessing information about an existing resource in any case where the provider has a suitable data source. I'd even go so far as to recommend the external data source over the terraform_remote_state data source if there's another way to get at that information (eg through a cloud providers CLI) just because the terraform_remote_state data source is particularly clunky.