I already have an environment running, but want to scale up the machine sizes. But keep getting a very similar error to this:
UPDATE operation on this environment failed 3 minutes ago with the
following error message:
Composer Backend timed out. Currently running tasks are [stage:
CP_COMPOSER_AGENT_RUNNING
description: "No agent response published."
response_timestamp {
seconds: 1618203503
nanos: 291000000
}
].
The gcp docs say that the service account doesn't have required permissions. I check required permissions also in the docs. My personal account and service already have the role Environment and Storage Object Administrator. And the service account already has the role Cloud Composer v2 API Service Agent Extension. I don't understand which permission am I missing.
Service account that the composer uses has roles:
Cloud Composer v2 API Service Agent Extension
Editor
Environment and Storage Object Administrator
Service Account User
And my personal account has roles:
Editor
Environment and Storage Object Administrator
Service Account User
Storage Admin
Viewer
Related
gcloud auth list
Credentialed Accounts ACTIVE ACCOUNT
* xxxx#xxxx.com
To set the active account, run:
$ gcloud config set account `ACCOUNT
The credentials used here are correct and make sense, but when I run it HOPING it to be that user account, the error is saying that this service account does not have permissions needed in this environment. Which makes total sense! but! I can't figure out how to stop terraform from running as this service account and not as my own active user account.
Error: Error loading state: Failed to open state file at
gs://dxxxxdefault.tfstate: googleapi: got HTTP response code 403 with
body: AccessDeniedAccess
denied.terraform-win#xxxx.iam.gserviceaccount.com
does not have storage.objects.get access to the Google Cloud Storage
object.
The error message said that your service account terraform-win#xxxx.iam.gserviceaccount.com cannot access terraform state on Google Cloud Storage, you just need to add storage.objects.get permission to the service account to fix the error.
If you don't want Terraform to use this service account, you can remove impersonation settings in Terraform and environment variable GOOGLE_APPLICATION_CREDENTIALS.
I am trying to create basic Composer environment:
image version: 1.17.8/2.1.4
using service account with composer.worker permission
my own user has project.owner permission
public ip
All my attempts failed with following error:
Http error status code: 400
Http error message: BAD REQUEST
Errors in: [Web server]; Error messages:
The caller does not have permission
Required 'deploymentmanager.typeProviders.create' permission for 'projects/<my-project>/global/typeProviders/europe-west2-<name-id>-addons-gke-typer'
deploymentmanager.typeProviders.create is covered by Deployment Manager Type Editor, so I added this permission to both my account and service account, but the error remains the same.
Cloud Composer Service Agent account is present in the project without any modifications to its permissions.
Is there anything else I can check or something that I missed during the set up?
For an account (whether User Account or Service Account) to be able to create a Composer Environment, the account must have a composer.environments.create permission.
And according to Google Cloud's documentation on Cloud Composer Access Control,
The Composer Worker role provides the permissions necessary to run a Cloud Composer environment
VM and intended for service accounts.
The Composer Worker role is not intended for creation of environments thus, it does not have the composer.environments.create permission.
If you want your service account to be able to create a Composer environment, you will need to assign the role Composer Administrator and this has the composer.environments.create permission needed.
You may refer to Access Control for Cloud Composer for the complete list of permission for Composer Worker, Composer Administrator and other Composer related roles.
I tried to deploy an OpenVPN Access Server to Google Compute Engines and received the following error message:
openvpn-access-server-1-vm: {"ResourceType":"compute.v1.instance","ResourceErrorCode":"EXTERNAL_RESOURCE_NOT_FOUND","ResourceErrorMessage":"The resource 'PROJECT_ID-compute#developer.gserviceaccount.com' of type 'serviceAccount' was not found."}
PROJECT_ID is just a placeholder for my own PROJECT_ID.
In the cloud console, I can't find the "compute engine default service account" (I think, I accidentally deleted it last year). In the log files, I found in 2020 it's ACCOUNT_ID, so I tried to undelete it with the following command:
gcloud beta iam service-accounts undelete ACCOUNT_ID
I had no success, I received:
ERROR: (gcloud.beta.iam.service-accounts.undelete) NOT_FOUND: Not found; Not found AccountDataType for <numeric_id>
<numeric_id> was a 12-digit number.
I tried to disable and enable compute service to restore the default service account, but it wasn't successful, I received:
response:
'#type': type.googleapis.com/google.iam.admin.v1.ServiceAccount
serviceName: iam.googleapis.com
status:
code: 6
message: ALREADY_EXISTS
receiveTimestamp: '2021-08-05T06:45:55.798772716Z'
Because of this error, I tried to delete it, but this didn't work too.
Now I don't know what to do, to get the default service account back.
Is it still existing or not?
Why isn't it working?
Keep in mind, I'm talking about PROJECT_ID-compute#developer.gserviceaccount.com.
service-PROJECT_ID#compute-system.iam.gserviceaccount.com is existing and recreated each time I disable and enable the Compute Engine API again.
Thanks for helping.
Since the Service Account was deleted an year ago it cannot be undeleted using the following command,
gcloud beta iam service-accounts undelete ACCOUNT_ID
This only works for Service Accounts deleted fewer than 30 days ago. Undeleting a service account for more information.
Instead, we can create a new Service Account and grant an ‘Editor’ role to it. As a Default Compute Engine Service Account has the same role by default. Compute Engine default service account for more information.
Now, we can create a new Compute Engine VM using the new Service Account. Setting up a new instance to run as a service account for more information.
If we already have a running VM and the Service Account got deleted, As #John Hanley suggested, we can edit the VM instance in the Google Cloud Console and assign the new Service Account to the instance. Changing the service account and access scopes for an instance for more information.
To set the new Service Account as the Compute Engine Default Service Account on the project, we can use the following command,
gcloud alpha compute project-info set-default-service-account
But since the command is in the ‘alpha’ launch stage, it is not available for everyone.
Another workaround would be creating a new project and deploying our instance there.
I am getting the following error (Please see below) when I run my terraform apply.
I am running Terraform 12.x.
GCP Cloud Build runs in a different project other than project-abcd (where these accounts are)
My terraform code tries execute a gcloud command in a GCP cloud build container. It does so by impersonating as composer-bq-sa#prj-abcd.iam.gserviceaccount.com
The service account that terraform runs as is:
terraform_service_account = "org-terraform#abcd.iam.gserviceaccount.com"
(before impersonating)
This IAM account (org-terraform#abcd.iam.gserviceaccount.com) (NOT service account) has the following role bindings (TOTAL 9):
(There is no Service Account with that email)
Composer Administrator
Compute Network Admin
Service Account Token Creator
Owner
Access Context Manager Admin
Security Admin
Service Account Admin
Logs Configuration Writer
Security Center Notification Configurations Editor
The service account (composer-bq-sa#prj-abcd.iam.gserviceaccount.com) has as one of its members: org-terraform#abcd.iam.gserviceaccount.com
When I look at the screen titled "Members with access to this service account" and look at org-terraform#abcd.iam.gserviceaccount.com , I see that it has the following role-bindings (ONLY 4):
Service Account Token Creator
Owner
Security Admin
Service Account Admin
Why am I getting the error below even though IAM account has apparently the right roles and it is one of the members of the service account it is impersonating as?
ERROR
module.gcloud_composer_bucket_env_var.null_resource.run_command[0] (local-exec): WARNING: This command
is using service account impersonation. All API calls will be executed as [**composer-bq-sa#prj-abcd.iam.gserviceaccount.com**].
module.gcloud_composer_bucket_env_var.null_resource.run_command[0] (local-exec): ERROR:
(gcloud.composer.environments.update) Failed to impersonate [**composer-bq-sa#prj-abcd.iam.gserviceaccount.com**]. Make sure the account that's trying to impersonate it has access to the service account itself and the "roles/iam.serviceAccountTokenCreator" role.
Recapping:
In order to grant user permission to impersonate a Service Account follow instructions listed in this document.
Depending on the use case, you may grant user following roles:
roles/iam.serviceAccountUser
roles/iam.serviceAccountTokenCreator
roles/iam.workloadIdentityUser
I want to compare Google Cloud Run to both Google App Engine and Google Cloud Functions. The Cloud Run Quickstart: Build and Deploy seems like a good starting point.
My Application Default Credentials are too broad to use during development. I'd like to use a service account, but I struggle to configure one that can complete the quickstart without error.
The question:
What is the least privileged set of predefined roles I can assign to a service account that must execute these commands without errors:
gcloud builds submit --tag gcr.io/{PROJECT-ID}/helloworld
gcloud beta run deploy --image gcr.io/{PROJECT-ID}/helloworld
The first command fails with a (seemingly spurious) error when run via a service account with two roles: Cloud Build Service Account and Cloud Run Admin. I haven't run the second command.
Edit: the error is not spurious. The command builds the image and copies it to the project's container registry, then fails to print the build log to the console (insufficient permissions).
Edit: I ran the second command. It fails with Permission 'iam.serviceaccounts.actAs' denied on {service-account}. I could resolve this by assigning the Service Account User role. But that allows the deploy command to act as the project's runtime service account, which has the Editor role by default. Creating a service account with (effectively) both Viewer and Editor roles isn't much better than using my Application Default Credentials.
So I should change the runtime service account permissions. The Cloud Run Service Identity docs have this to say about least privileged access configuration:
This changes the permissions for all services in a project, as well
as Compute Engine and Google Kubernetes Engine instances. Therefore,
the minimum set of permissions must contain the permissions required
for Cloud Run, Compute Engine, and Google Kubernetes Engine in a
project.
Unfortunately, the docs don't say what those permissions are or which set of predefined roles covers them.
What I've done so far:
Use the dev console to create a new GCP project
Use the dev console to create a new service account with the Cloud Run Admin role
Use the dev console to create (and download) a key for the service account
Create (and activate) a gcloud configuration for the project
$ gcloud config list
[core]
account = {service-account-name}#{project-id}.iam.gserviceaccount.com
disable_usage_reporting = True
project = {project-id}
[run]
region = us-central1
Activate the service account using the downloaded key
Use the dev console to enable the Cloud Run API
Use the dev console to enable Container Registry→Settings→Container Analysis API
Create a sample application and Dockerfile as instructed by the quickstart documentation
Run gcloud builds submit --tag gcr.io/[PROJECT-ID]/helloworld
...fails due to missing cloud build permissions
Add the Cloud Build Editor role to service account and resubmit build
...fails due to missing storage permissions. I didn't pay careful attention to what was missing.
Add the Storage Object Admin role to service account and resubmit build
...fails due to missing storage bucket permissions
Replace service account's Storage Object Admin role with the Storage Admin role and resubmit build
...fails with
Error: (gcloud.builds.submit) HTTPError 403:
<?xml version='1.0' encoding='UTF-8'?>
<Error>
<Code>AccessDenied</Code>
<Message>Access denied.</Message>
<Details>
{service-account-name} does not have storage.objects.get access to
{number}.cloudbuild-logs.googleusercontent.com/log-{uuid}.txt.</Details>
</Error>
Examine the set of available roles and the project's automatically created service accounts. Realize that the Cloud Build Service Account role has many more permissions that the Cloud Build Editor. This surprised me; the legacy Editor role has "Edit access to all resources".
Remove the Cloud Build Editor and Storage Admin roles from service account
Add the Cloud Build Service Account role to service account and resubmit build
...fails with the same HTTP 403 error (missing get access for a log file)
Check Cloud Build→History in the dev console; find successful builds!
Check Container Registry→Images in the dev console; find images!
At this point I think I could finish Google Cloud Run Quickstart: Build and Deploy. But I don't want to proceed with (seemingly spurious) error messages in my build process.
Cloud Run PM here:
We can break this down into the two sets of permissions needed:
# build a container image
gcloud builds submit --tag gcr.io/{PROJECT_ID}/helloworld
You'll need:
Cloud Build Editor and Cloud Build Viewer (as per #wlhee)
# deploy a container image
gcloud beta run deploy --image gcr.io/{PROJECT_ID}/helloworld
You need to do two things:
Grant your service account the Cloud Run Deployer role (if you want to change the IAM policy, say to deploy the service publicly, you'll need Cloud Run Admin).
Follow the Additional Deployment Instructions to grant that service account the ability to deploy your service account
#1
gcloud projects add-iam-policy-binding PROJECT_ID \
--member="serviceAccount:{service-account-name}#{project-id}.iam.gserviceaccount.com" \
--role="roles/run.developer"
#2
gcloud iam service-accounts add-iam-policy-binding \
PROJECT_NUMBER-compute#developer.gserviceaccount.com \
--member="serviceAccount:{service-account-name}#{project-id}.iam.gserviceaccount.com" \
--role="roles/iam.serviceAccountUser"
EDIT: As noted, the latter grants your service account the ability to actAs the runtime service account. What role this service account has is dependent on what it needs to access: if the only thing Run/GKE/GCE accesses is GCS, then give it something like Storage Object Viewer instead of Editor. We are also working on per-service identities, so you can create a service account and "override" the default with something that has least-privilege.
According to https://cloud.google.com/cloud-build/docs/securing-builds/set-service-account-permissions
"Cloud Build Service Account" - Cloud Build executes your builds using a service account, a special Google account that executes builds on your behalf.
In order to call
gcloud builds submit --tag gcr.io/path
Edit:
Please "Cloud Build Editor" and "Viewer" your service account that starts the build, it's due to the current Cloud Build authorization model.
Sorry for the inconvenience.