Error Deploying Cloud Function from gitlab - google-cloud-platform

I am trying to deploy a cloud function via gitlab using a new service account (Not using default service account). It has the cloud functions developer role but it is still failing with below error:
The error below includes a user as cloud-functions-mixer. I haven't configured anything like that in my repo and not sure why it is coming up.
First of all, running the suggested command doesn't even work because the suggested syntax is bad . I have tried running the below command but it’s not right
Error: googleapi: Error 403: Missing necessary permission iam.serviceAccounts.actAs for cloud-functions-mixer on the service account project-test-tf-02#appspot.gserviceaccount.com.
Grant the role 'roles/iam.serviceAccountUser' to cloud-functions-mixer on the service account project-test-tf-02#appspot.gserviceaccount.com.
You can do that by running 'gcloud iam service-accounts add-iam-policy-binding project-test-tf-02#appspot.gserviceaccount.com --member=cloud-functions-mixer --role=roles/iam.serviceAccountUser'.

Google's instructions about the cloud-functions-mixer are wrong. What you actually need to do is replace the string cloud-functions-mixer with the name of the service account that is building or deploying your function.
The following user-defined service accounts will be used in an example:
my-cloud-function#my-project.iam.gserviceaccount.com is the service account that your function runs as.
build-service-account#my-project.iam.gserviceaccount.com is the service account that builds/deploys your Cloud Function
The command to run is:
gcloud iam service-accounts add-iam-policy-binding
my-cloud-function#my-project.iam.gserviceaccount.com
--member=serviceAccount:build-service-account#my-project.iam.gserviceaccount.com
--role=roles/iam.serviceAccountUser
Docs
Or, in Terraform, you would need a resource like this:
resource "google_service_account_iam_member" "opentok_webhook_mixer" {
service_account_id = google_service_account.my_cloud_function.id
role = "roles/iam.serviceAccountUser"
member = "serviceAccount:${google_service_account.build_service_account.email}"
}
You'll have to update the names of the service account resources.
This approach also works for Google Cloud Build.

Related

Build failed: could not resolve source: googleapi: Error 403: Unknown service account showing up in error message

Build failed: could not resolve source: googleapi: Error 403: 909263763911#cloudbuild.gserviceaccount.com does not have storage.objects.get access to the Google Cloud Storage object., forbidden com.google.net.rpc3.client.RpcClientException: <eye3 title='/ArgoAdminNoCloudAudit.CreateBuild, INVALID_ARGUMENT'/> APPLICATION_ERROR;google.devtools.cloudbuild.v1/ArgoAdminNoCloudAudit.CreateBuild;could not resolve source: googleapi: Error 403: 909263763911#cloudbuild.gserviceaccount.com does not have storage.objects.get access to the Google Cloud Storage object., forbidden;AppErrorCode=3;StartTimeMs=1665066353404;unknown;ResFormat=AUTOMATIC;ServerTimeSec=0.046704348;LogBytes=256;Non-FailFast;EndUserCredsRequested;EffSecLevel=none;ReqFormat=AUTOMATIC;ReqID=17f5636ce15f4efa;GlobalID=0;Server=[2002:a65:f1ea:0:b0:46:3bbe:5444]:4001
However when I run "gcloud iam service-accounts list" , I dont see the specified account. I do see an account that looks similar but the email was different. Am I doing something wrong?
`gcloud iam service-accounts list
DISPLAY NAME EMAIL DISABLED
firebase-adminsdk firebase-adminsdk-80bfr#algo-321412.iam.gserviceaccount.com False
dbconnector dbconnector#algo-321412.iam.gserviceaccount.com False
Compute Engine default service account 909263763911-compute#developer.gserviceaccount.com False
gmailsenderAlgo gmailsenderalgo#algo-321412.iam.gserviceaccount.com False
App Engine default service account algo-321412#appspot.gserviceaccount.com False`
The command gcloud iam service-accounts list list all the service account of your current project. Those service accounts have this pattern <custom name that you provide>#<projectID>.iam.gserviceaccount.com. The projectID is algo-321412 in your case
This time, the service account has a different format 909263763911#cloudbuild.gserviceaccount.com. It doesn't belong to your project, but to Cloud Build service. The prefix 909263763911 is your project number. This service account is named "Cloud Build default service account"
When you run a Cloud Build job, and if you don't mention any custom service account to use, the Cloud Build default service account is used and all the default Cloud API call (through GCLOUD or through piece of custom code) use this service account.
In your case, you have some missing permission on that default service account. Grant the required permissions (copy the service account and add the correct role at the correct level of the resource). Or use a custom service account, with the correct permission and use it in Cloud Build jobs.

How To Grant GCP Organization Level Permissions to Service Account via Command Line

I'm trying to create a data source in terraform to get information about a Google billing account.
data "google_billing_account" "ac" {
display_name = "foo-Billing"
open = true
}
But terraform throws the error Error: Billing account not found: foo-Billing which looks like my service account lacks the required permissions to do this, as the billing account definitely exists.
I'm able to run this command
gcloud projects add-iam-policy-binding main1-project --member=serviceAccount:$ID --role=roles/ROLE_NAME
which works fine with just about any other role binging except that of billing.admin which throws the error
ERROR: (gcloud.projects.add-iam-policy-binding) INVALID_ARGUMENT: Role (roles/billing.admin) does not exist in the resource's hierarchy.
I'm faily new to GCP so I"m not sure how to go about fixing this.
Is there a way to grant billing.admin permissions to a service account from the command line?
Maybe another API to call or something.
I'm able to grant the permission from the UI which then makes my terraform command work, but I would like to be able grant it from the command line.
You're getting this error because you're trying to assign the billing admin role from the project level but it can only be done at the organization level.
If you have an organization, then the same command should work with a slight tweak.
gcloud organizations add-iam-policy-binding ORGANIZATION --member=serviceAccount:$ID --role=roles/billing.admin
You should be able to get a list of your organizations using
gcloud organizations list
If you don't have any, then just create one.
You'll just need a Gsuite or Cloud Identity account.

What predefined IAM roles does a service account need to complete the Google Cloud Run Quickstart: Build and Deploy?

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.

How do I use gcloud with a service account?

I'm having trouble getting gcloud to access my project as a service account
Installed the gcloud sdk for Windows on my local machine
Created a new service account on Google Cloud Platform console
Gave the service account the Compute Admin role
Authorized gcloud as the service account:
gcloud auth activate-service-account --key-file=keyfile.json
Issued the command
gcloud compute zones list
I get the following error:
ERROR: (gcloud.compute.zones.list) Some requests did not succeed:
- Required 'compute.zones.list' permission for '<project id>'
I verified the Compute Admin role has the proper compute.zones.list permission.
What am I missing?
I fixed the issue by recreating the service account.
It seems there's a screen that asks about the roles you want the service account to have as you create it. I originally assigned the roles after the fact.

gcloud: The user does not have access to service account "default"

I attempting to use an activated service account scoped to create and delete gcloud container clusters (k8s clusters), using the following commands:
gcloud config configurations create my-svc-account \
--no-activate \
--project myProject
gcloud auth activate-service-account my-svc-account#my-project.iam.gserviceaccount.com \
--key-file=/path/to/keyfile.json \
--configuration my-svc-account
gcloud container clusters create a-new-cluster \
--configuration my-svc-account \
--project= my-project
--zone "my-zone"
I always receive the error:
...ERROR: (gcloud.container.clusters.create) ResponseError: code=400, message=The user does not have access to service account "default".
How do I grant my-svc-account access to the default service account for GKE?
After talking to Google Support, the issue was that the service account did not have a "Service Account User" permissions activated. Adding "Service Account User" resolves this error.
Add the following role to the service account who makes the operation:
Service Account User
Also see:
https://cloud.google.com/kubernetes-engine/docs/how-to/iam#service_account_user
https://cloud.google.com/iam/docs/service-accounts#the_service_account_user_role
https://cloud.google.com/iam/docs/understanding-roles
For those that ended up here trying to do an Import of Firebase Firestore documents with a command such as:
gcloud beta firestore import --collection-ids='collectionA','collectionB' gs://YOUR_BUCKET
I got around the issue by doing the following:
From the Google Cloud Console Storage Bucket Browser, add the service account completing the operation to the list of members with a role of Storage Admin.
Re-attempt the operation.
For security, I revoked the role after the operation completed, but that's optional.
iam.serviceAccounts.actAs is the exact permission you need from Service Account User
I was getting the The user does not have access to service account... error even though I added the Service Account User role as others have suggested. What I was missing was the organization policy that prevented service account impersonation across projects. This is explained in the docs: https://cloud.google.com/iam/docs/impersonating-service-accounts#enabling-cross-project
Added Service Account User role to service account and it worked for me.