Building a bastion instance to run terraform: issue with API access

0
votes

TL;DR. Can't figure out what APIs scope needs to be enabled on bastion instance. Also, any advise on building bastion instance?

I'm working on a bastion instance from which I'd like to run terraform plan / terraform apply commands.

My plan for bastion instance is this:

  1. set up OS Login,
  2. set up two-factor authentication,

  3. make sure default service account has access to GCP resources (for terraform to be able to access resources):

    If you're running Terraform from a GCE instance, default credentials are automatically available. See Creating and Enabling Service Accounts for Instances for more details.

    reference

  4. store terraform configs on the instance, be able terraform plan / terraform apply

After doing items 1, 3 and 4 from the list above I am having a problem with terraform accessing service account management API - running terraform plan results in the following:

$ terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.

google_service_account.terraform_state_user: Refreshing state... [id=projects/xxxxxxxx-xxxxxx-xxxxxx/serviceAccounts/terraform-state-user@xxxxxxxx-xxxxxx-xxxxxx.iam.gserviceaccount.com]
google_storage_bucket.access_logs: Refreshing state... [id=xxxxxxxx-bucket-access-logs]
google_storage_bucket.terraform_state_storage: Refreshing state... [id=xxxxxxxx-terraform-state-storage]

Error: Error reading Service Account "projects/xxxxxxxx-xxxxxx-xxxxxx/serviceAccounts/terraform-state-user@xxxxxxxx-xxxxxx-xxxxxx.iam.gserviceaccount.com": googleapi: Error 403: Request had insufficient authentication scopes., forbidden

As PoC fix I have changed the list of Cloud API access scopes on the bastion VM to Allow full access to all Cloud APIs. After doing so, terraform plan and terraform apply commands succeeded. As a next step, I decided to limit the number of API scopes the instance has access to but found myself unable to find correct set of APIs scopes to access Service Account API (I get the error as indicated above).

After a couple of attempts to terraform plan and terraform apply to work. This is the list of API scopes I have on bastion right now:

Bigtable Admin              Disabled
Bigtable Data               Disabled
Cloud Datastore             Disabled
Cloud Debugger              Disabled
Cloud Pub/Sub               Disabled
Cloud Source Repositories   Disabled
Cloud SQL                   Disabled
Compute Engine              Read Write
Service Control             Enabled
Service Management          Read Write
Stackdriver Logging API     Write Only
Stackdriver Monitoring API  Write Only
Stackdriver Trace           Write Only
Storage                     Read Write
Task queue                  Disabled
User info                   Enabled

I'm trying to find answers to the following questions:

  1. what API scope should I enable to be able to read / write service account resources?
  2. provided I am SSHing into bastion via "OS Login" feature (which depends on IAM role my own user) is my own account used to access the APIs, or is it Default Service Account? (this is just to aid my understanding),
  3. any general advise on building bastion instance?
1
google-cloud-platformterraformservice-accountsterraform-provider-gcp
1) Ask one question per post. 2) You are trying to control the wrong item (scopes). You should be managing the roles assigned to the Compute Engine Default Service Account. However, Terraform requires whatever permissions are required for the services you are building. That varies from one script to another. Spend some time learning what service accounts are, IAM roles and Terraform. Then you will be able to configure the correct permissions for each type of Terraform activity. – John Hanley
In this case, it might make sense to create a service account specifically for this use with the exact permissions you need and running the instance as that service account, rather than trying to wedge it into using the default account. – robsiemb

1 Answers

0
votes

The usage of a dedicated VM for deploying a Terraform script is often a problem and that's why I didn't like Terraform. But I found a way to perform this in serverless and thus to avoid to create a VM and to maintain it: I use Cloud Build and a Terraform container.

I wrote this article on this if you want to know more.