0

I am creating a VM in GCP's Compute Engine with a service account that has permissions to read from a particular Cloud Storage bucket that contains some common configuration that may contain sensitive information, such as TLS certs. However when my startup script is executed, it is denied permission to access the bucket because it is using the Google Compute Engine default service account, not the service account I provisioned my VM to use. Can someone please help me figure out how to ensure that the startup script uses the right service account?

============= EDIT =============

Not sure how helpful this will be, but here is the puppet code that is failing, I can't/won't provide all of the puppet code. The actual startup script that is invoked when the instance starts is sudo puppet apply --verbose /opt/puppet/manifests/opensearch.pp >/var/log/puppetlabs/puppet/startup.log 2>&1. Note that I've already confirmed that puppet is not doing anything special with the service accounts. However puppet always uses the default service account, and fails to download the certs. If I SSH into the instance and run the same command by hand it works every time.

      exec { 'download_ssl_certs':
        command => "/snap/bin/gsutil cp -r gs://${opensearch::secrets_bucket}/${opensearch::cluster}/* ${opensearch::opensearch_path}/config/",
        notify  => Exec['ssl_certs_chown']
      }

      exec { 'ssl_certs_chown':
        command     => "/bin/chown -R ${opensearch::service_user}:${opensearch::service_group} ${opensearch::opensearch_path}/config",
        onlyif      => "/bin/ls -lhR ${opensearch::opensearch_path}/config | /bin/grep -i root | grep -v ${opensearch::service_user}",
        refreshonly => true,
        notify => Service['opensearch'],
      }
Brandon
  • 890
  • 2
  • 13
  • 32
  • Edit your question and include the startup script. Unless the apps in your script specify a service account, the service account attached to the instance will be used for credentials. – John Hanley Apr 25 '22 at 18:38
  • Added more of my code, although what you're saying doesn't match the behavior I'm seeing. – Brandon Apr 25 '22 at 20:00
  • Your code is not specifying a service account, either explicitly or implicitly via ADC. Your user account sets up a different authorization path than the system's account. – John Hanley Apr 25 '22 at 20:01
  • I recommend that you set the service account to be used by attaching it to the instance. Another option is to setup authorization using a service account within Puppet for Google Cloud. https://forge.puppet.com/modules/google/gauth – John Hanley Apr 25 '22 at 20:04

1 Answers1

2

Example:

gcloud compute instances create example-vm \
    --service-account 123-my-sa@my-project-123.iam.gserviceaccount.com \
    --scopes https://www.googleapis.com/auth/cloud-platform

Creating and enabling service accounts for instances

As the service account are part of metadata, you can access to metadata using startup scripts.

Accessing metadata from a Linux startup script

Alejandro F.
  • 410
  • 3
  • 10
  • This is what I had been doing all along, although via Terraform. My only guess as to how the same Terraform code gave me the issue I described above and the expected behavior today is that GCP was giving me some funky behavior while provisioning my VMs on the day in question. Either that or I'm going insane. – Brandon May 02 '22 at 18:04