Im trying to get my compute engine instance to communicate with Cloud SQL using the Proxy. I keep getting this error when I try to start the proxy:
the default Compute Engine service account is not configured with
sufficient permissions to access the Cloud SQL API from this VM.
Please create a new VM with Cloud SQL access (scope) enabled under
"Identity and API access". Alternatively, create a new "service
account key" and specify it using the -credentials_file parameter
When I describe my instance using gcloud compute instances describe the service account and scopes are:
serviceAccounts:
- email: 123456-compute#developer.gserviceaccount.com
scopes:
- https://www.googleapis.com/auth/devstorage.full_control
- https://www.googleapis.com/auth/logging.write
- https://www.googleapis.com/auth/monitoring.write
- https://www.googleapis.com/auth/sqlservice
- https://www.googleapis.com/auth/sqlservice.admin
I can get this working if I create a new instance with full scope permissions:
serviceAccounts:
- email: 123456-compute#developer.gserviceaccount.com
scopes:
- https://www.googleapis.com/auth/cloud-platform
But this seems less secure than just specifying the scopes I need.
It is an issue fixed in https://github.com/GoogleCloudPlatform/cloudsql-proxy/pull/21.
We will roll out a new release on Monday (4/18). Or you can compile from the source on github. Sorry for the inconvenience.
Related
Keep getting this error:
Error, failed to create instance group-database-instance: googleapi: Error 403: Request had insufficient authentication scopes.
More details:
Reason: insufficientPermissions, Message: Insufficient Permission
I have added a service account with editor permissions to use all gcp resources and added directed terraform to a credentials file generated.
Would this be an error in the code or something else?
Based on the error message you have provided and the task you would like to accomplish, it would seem that you might need to add a scope when creating your instance.
To use the Google Kubernetes Engine API for a GCE virtual machines, you will need to add the Cloud Platform Scope ("https://www.googleapis.com/auth/cloud-platform") to your VM when it is created.
Additionally, if you are using the gcloud command-line, you can follow along with something like:
gcloud compute instances create NAME --scopes=https://www.googleapis.com/auth/cloud-platform
If you are using the Cloud Console UI, when you are creating a VM instance, look for the "Identity and API access" section, and select "Allow full access to all Cloud APIs".
I want to write a Google Cloud Function that can interact with GCP's Dataproc service to programatically launch Dataproc clusters. We already have a battle-hardened Dataproc infrastructure, we're just looking to extend the ways in which they get launched.
Our Dataproc clusters can only be launched using an appropriate IAM service account that is already a member of the appropriate IAM roles hence the Cloud Function will need to authenticate to the Dataproc service using that service account. What is the most appropriate way for a Cloud Function to authenticate to other GCP services/APIs using a service account?
Options I suspect include:
* running the function as that service account
* providing a JSON key file & setting GOOGLE_APPLICATION_CREDENTIALS environment variable
Is there a recognised way of achieving this?
I have had a look at :
* https://cloud.google.com/docs/authentication/
* https://cloud.google.com/docs/authentication/getting-started
but they are not specific to Cloud Functions.
I've also looked at
* https://cloud.google.com/functions/docs/writing/http
but that seems more concerned with how the caller of the function can authenticate.
I think this is what you're looking for: https://cloud.google.com/functions/docs/concepts/iam
At runtime, Cloud Functions defaults to using the App Engine default service account (PROJECT_ID#appspot.gserviceaccount.com), which has the Editor role on the project. You can change the roles of this service account to limit or extend the permissions for your running functions. You can also change which service account is used by providing a non-default service account on a per-function basis.
tl;dr gcloud functions deploy FUNCTION_NAME --service-account SERVICE_ACCOUNT_EMAIL
By the way, if you ever need more complex scheduling logic, consider looking into Cloud Composer (managed Apache Airflow): https://cloud.google.com/composer/
MacBook-Air-2:~ Owner$ gcloud sql instances describe ahaha-mysql
ERROR: (gcloud.sql.instances.describe) There was no instance found at projects/ahaha-20180621/instances/ahaha-mysql or you are not authorized to access it.
You will need to enable permission for the compute instance to access the cloud sql
Stop the instance
Edit the instance and change the Cloud API access scopes
Enable Cloud SQL
Restart the instance
run gcloud auth login and authenticate as yourself by following the link (you might need to fix it in a text editor) and entering the verification code.
run gcloud sql instances describe ahaha-mysql this should now work
From my workstation I can fire templated Dataflow jobs with the gcloud dataflow jobs command. The required authorization to insert a new job come from my workstation where I'm logged in.
On the Compute Engine instance I rely on it's service account. The one with (number)-compute#. Within the AIM section I enabled Dataflow/Dataflow Admin, Dataflow/Dataflow Developer and Dataflow/Dataflow Worker for this service account to be safe.
I even added Cloud Dataflow Service Agent when I came across that one.
Then I try to start a Dataflow from the command line but I get an error about insufficient authentication scopes: ERROR: (gcloud.dataflow.jobs.run) PERMISSION_DENIED: Request had insufficient authentication scopes.
If I do a gcloud config auth and login with my personal account, of course, it works.
Somehow I'm missing the proper permissions to set to the applied service account.
Is there a guideline I missed? Can somebody please point me into the right direction?
The error message indicates that the instance does not setup access scope properly. To launches a job from a GCE VM, the VM must have compute.read-only, compute, or cloud-platform scope for the project.
The way to verify it is using the command "gcloud compute instances describe --zone=[zone][instance]" and look for "scopes".
This document and this existing question may provide useful guidelines for you.
Our team is trying to troubleshoot an issue we have been encountering with service accounts. The service account we are using is able to create a disk and IP address, however an error is thrown when an instance request is created. All resources can be listed (ie. networks, snapshots, etc.). I have attached a small console snippet below.
The service account is successfully authenticated with JSON key given to me. I have tried altering permissions of the service account and created a new key.
Any assistance is greatly appreciated.
Created [https://www.googleapis.com/compute/v1/projects/<PROJECT>/zones/asia-east1-c/disks/dev-josh-ui-test-08].
Created [https://www.googleapis.com/compute/v1/projects/<PROJECT>/regions/asia-east1/addresses/dev-josh-ui-test-08-ip].
ERROR: (gcloud.compute.instances.create) Some requests did not succeed:
- The resource '<ID>-compute#developer.gserviceaccount.com' of type 'serviceAccount' was not found.
I was able to get the exact error provided:
The resource '-compute#developer.gserviceaccount.com' of type 'serviceAccount' was not found.
by deleting my default compute service account and attempting to create an instance through the Cloud Shell, so I assume this is the issue.
If the default compute service account was somehow deleted, if has been less than 30 days, you can restore it using: gcloud beta iam service-accounts undelete [ACCOUNT_ID]
https://cloud.google.com/iam/docs/creating-managing-service-accounts#undeleting
After this, you will have to go into https://console.cloud.google.com/apis/dashboard and disable and re-enable the compute engine API. This will take a few moments, but after the GCE API is re-enabled you should be able to create VMs through the Cloud Shell again and I was able to reproduce this.
On https://console.cloud.google.com/apis/dashboard disable the "google compute engine API" and after enable it again.
The enabling also creates some additional setup that is needed to use the API. Those resources could have been deleted by accident beforehand.
You might need to have some patience and wait a minute or two between disabling and enabling.