Search code examples
google-cloud-platformgoogle-oauthgoogle-compute-enginegoogle-secret-manager

Accessing Google Secrets from an application running on a Google Cloud VM instance - Assigning Cloud APIs to VM


I'm using Google Secrets to store API keys and other application specific "secrets". When I deploy my application to a VM instance using a docker container, I want it to access the Google Secrets using the VM's associated service account.

I have gotten this working using the following:

  • Assigning the "Secret Manager Secret Accessor" permission to the Service Account.enter image description here
  • Giving my VM access to all APIs:
  • enter image description here

From a security perspective and recommended best practice, I don't want to give access to all APIs. The default access option doesn't work and I can't figure out from the list which options to enable to allow access to Google Secrets from my VM.

enter image description here

TLDR - Which Cloud API(s) do I need to give my Google Compute VM instance access to so that it can access Google Secrets without giving it access to all of the Cloud APIs?


Solution

  • According to the Secret Manager documentation, you need the cloud-platform OAuth scope.

    Note: To access the Secret Manager API from within a Compute Engine instance or a Google Kubernetes Engine node (which is also a Compute Engine instance), the instance must have the cloud-platform OAuth scope. For more information about access scopes in Compute Engine, see Service account permissions in the Compute Engine documentation.

    I'm not sure you can set this scope in the web UI, though you can set it through the command line.

    Possible Alternative

    What I do, rather than setting scopes on VMs, is create a service account specifically for the VMs (instead of using the default service account) and then give this service account access to specific resources (like the specific Secrets it should have access to, rather than all of them). When you do this in the web UI, the access scopes disappear and you are instructed to use IAM roles to control VM access like so:

    Custom Service Account