Cloud build service account permission to build - google-cloud-platform

I have my env set as Cloud build app (Github app) to provision terraform through cloud build
to Google Cloud Platform. The build is a simple cloud composer with cloud functions, that creates these resources along with the right service accounts and members.
However, only the owner permission can execute this successfully, I want to have least privilege for the cloud build service account. I have used a lot of roles and nothing seems to be successful. i.e. create service account, editor, access context manager admin, access approval approver. When I run the build via github commit, I receive this error other than having the owner set as role
Error: Error applying IAM policy for cloudfunctions cloudfunction
googleapi: Error 403: Permission
Error: Batch "iam-project-redacted modifyIamPolicy" for request
"Create IAM Members roles/composer.worker
serviceAccount:composer-env-account#redacted.iam.gserviceaccount.com
for \"project \\"redacted\\"\"" returned error: Error applying IAM
policy for project "redacted": Error setting IAM policy for project
"redacted": googleapi: Error 403: The caller does not have permission,
forbidden. To debug individual requests, try disabling batching:
https://www.terraform.io/docs/providers/google/guides/provider_reference.html#enable_batching
Is there a IAM policy/role that allows for service accounts to successfully build through cloud build?
With Owner role set to cloudbuild service account, everything build successfully

The Cloud Build service account has assigned by default the Cloud Build Service Account role which has the permissions referred here. Notice that you'll only be limited to perform the following tasks: which include doing the pertinent activities in order to make a build successful (accessing Cloud Source Repository, Cloud Storage and Container Registry).
Along with the Cloud Build Service Account role, you'll need to grant additional roles depending on what else you are doing with Cloud Build.
In the particular case of your error message you'll need to add the Cloud Functions Developer role in order to be able to get full access to Cloud Functions. The whole procedure is documented here.
There are similar roles if you are also deploying to App Engine, or managing Google Kubernetes Engine, etc. Find all the list of available roles here.

Related

GCP cloud build: CLOUD_BUILD_UNAVAILABLE

I try to run cloud deploy on existing project where also run Cloud Build and
I have the following error:
targetRenders:
qsdev:
failureCause: CLOUD_BUILD_UNAVAILABLE
renderingState: FAILED
I try to use this article when I try to run a cloud deploy on a new empty project everything works as expected.
I understand that the problem is with the permissions but can’t find where exactly.
I used this help
What could be the problem?
As shown in the FailureCause documentation, this error is caused by insufficient permissions.
CLOUD_BUILD_UNAVAILABLE: Cloud Build is not available, either because it is not enabled or because Google Cloud Deploy has insufficient permissions. See Required permission.
In the required permission documentation, it shows some troubleshoot steps to follow in order to ensure that the correct permissions are set:
The service account used for rendering configurations must have sufficient permissions to access the Cloud Storage bucket where your Google Cloud Deploy resources are stored (delivery pipelines, releases, rollouts).
The role roles/clouddeploy.jobRunner includes all permissions the render service account (privatePool or defaultPool) needs.
The service account used for deploying must have sufficient permissions to deploy to the target cluster, and permission to access the Cloud Storage bucket.
Note: If you use a custom Cloud Storage bucket, you can put it anywhere. (It doesn't need to be in the same region, for example, as the delivery pipeline.)
The service account that calls Google Cloud Deploy to create a release must have the clouddeploy.releaser role. It must also have the iam.serviceAccount.actAs permission to use the service account that renders manifests (for example through the roles/iam.serviceAccountUser role).
The service account that calls Google Cloud Deploy to promote a release or create a rollout must have the iam.serviceAccount.actAs permission to use the service account that deploys to targets.

IAM issue with Google Cloud Run service account

I am trying to deploy my AutoML trained model using Cloud Run, but am having difficulties with IAM permissions. I'm using this as a guide, and keep getting the following error at the build step. I'm new to Cloud Run/GCP but as far as I can see, I have granted the right roles to the right accounts. I appreciate any assistance you can provide as I'm really stumped.
Error message:
Step #3: ERROR: (gcloud.run.deploy) User [REDACTED#cloudbuild.gserviceaccount.com] does not have permission to access namespaces instance [REDACTED] (or it may not exist):
Google Cloud Run Service Agent does not have permission to get access tokens for the service account REDACTED#cloudbuild.gserviceaccount.com.
Please give service-REDACTED#serverless-robot-prod.iam.gserviceaccount.com permission iam.serviceAccounts.getAccessToken on the service account.
Alternatively, if the service account is unspecified or in the same project you are deploying in, ensure that the Service Agent is assigned the Google Cloud Run Service Agent role roles/run.serviceAgent.
Here are the roles assigned to the Cloud Run Service Agent
Default service account has the Cloud Run Admin Role
Here are the accounts to which I've given access to the Default compute service account, the Cloud Build Service Agent and Cloud Run Service Agent are added:

CloudScheduler 403 Permission denied while creating

I am trying to create a Cron job programmatically in the CloudScheduler Google Cloud Platform using the following API explorer.
Reference: Cloud Scheduler Documentation
Even though I have given the user Owner permission and verified it in Policy Troubleshooter that it has cloudscheduler.jobs.create, I am still getting the following error.
{
"error": {
"code": 403,
"message": "The principal (user or service account) lacks IAM permission \"cloudscheduler.jobs.create\" for the resource \"projects/cloud-monitoring-saurav/locations/us-central\" (or the resource may not exist).",
"status": "PERMISSION_DENIED"
}
}
I had the same issue. The problem was that the region i specified did not support the cloud scheduler. You seem to have the same issue: "us-central" is not suppported. Try "us-central1"
The error is caused by using a service account that does not have an IAM role that includes the permission cloudscheduler.jobs.create. An example role is roles/cloudscheduler.admin aka Cloud Scheduler Admin. I have the feeling that you have mixed the permission of the service account that you use with Cloud Scheduler (at runtime, when a job triggers something) and the permission of the account currently creating the job (aka your account for example).
You actually need two service accounts for the job to get created. You need one that you set up yourself (can be whatever name you like and doesn't require any special permissions) and you also need the one for the default Cloud Scheduler itself ( which is managed by Google)
Use an existing service account to be used for the call from Cloud Scheduler to your HTTP target or you can create a new service account for this purpose. The service account must belong to the same project as the one in which the Cloud Scheduler jobs are created. This is the client service account. Use this one when specifying the service account to generate the OAuth / OICD tokens.
If your target is part of Google Cloud, like Cloud Functions/Cloud Run update your client service account by granting it the necessary IAM role (Cloud function invoker for cloud functions and Cloud Run Invoker for Cloud Run).The receiving service automatically verifies the generated token. If your target is outside of Google Cloud, the receiving service must manually verify the token.
The other service account is the default Cloud Scheduler service account which must also be present in your project and have the Cloud Scheduler Service Agent role granted to it. This is so it can generate header tokens on behalf of your client service account to authenticate to your target. The Cloud Scheduler service account with this role granted is automatically set up when you enable the Cloud Scheduler API, unless you enabled it prior to March 19, 2019, in which case you must add the role manually.
Note : Do not remove the service-YOUR_PROJECT_NUMBER#gcp-sa-cloudscheduler.iam.gserviceaccount.com service account from your project, or its Cloud Scheduler Service Agent role. Doing so will result in 403 responses to endpoints requiring authentication, even if your job's service account has the appropriate role.
In my case it required the permission: cloudscheduler.jobs.delete.
I found the role the by permission name: https://cloud.google.com/iam/docs/permissions-reference
It was Cloud Scheduler Admin (roles/cloudscheduler.admin)
Then I added it to my service account roles.

Cloud Run - Allowing users to deploy a single resource, based on permissions

I'm almost having an headache while trying to allow access on GCP Cloud Run for different users, for a specific service using permission attributes.
Let's consider I have different services running, and I want to assign my developers to use gcloud run deploy only on a bunch of them. In my case, this is like as following:
backend-service > revisions can be deployed by backend-user only;
frontend-service > revisions can be deployed by frontend-user only;
Both users have "Cloud Run Developer" role, and both services account have the "ServiceAccountUser" role as described here in GCP docs
The issue I'm facing however is when I try to restrict user permissions for a single resource.
Using the GCP web console, I've created a condition based on Resource > Name to be backend-service.
I instantly get this error when using gcloud run deploy:
ERROR: (gcloud.run.deploy) PERMISSION_DENIED: Permission 'run.services.update' denied on resource 'namespaces/PROJECT_ID/services/SERVICE_NAME' (or resource may not exist).
make: *** [deploy] Error 1
As I could not find anything related to IAM permission conditions related to Cloud Run (they're not even listed afaik) I tried changing the Resource > Name condition value to namespaces/PROJECT_ID/services/SERVICE_NAME, but that didn't work too.
As a side note, when checking permissions inside Cloud Run Web Console it shows
Condition on Cloud Run Developer
{
"expression": "resource.name == \"backend-service\"",
"title": "BackendService"
}
Cloud Run doesn't support IAM conditions. You have several workarounds
Wait for an update
Create different projects
Automate the deployment (only the CI/CD pipeline can deploy, not directly the users)
Add permissions at the resource level and not at the project level.

How to programatically add Roles to cloud build service account?

I am trying to use setIAMPolicy for Cloud Build Service account #cloudbuild.gserviceaccount.com. I want to provide AppEngine Admin, Cloud Run Admin permissions to the Cloud Build Service member so that it can do automated releases on AppEngine.
Somehow it throws 404 when I pass resource of Cloud Build Service account while getting IAM Policy. To confirm, I tried GET https://iam.googleapis.com/v1/{name=projects/*}/serviceAccounts in API Explorer and it also does not return the Google Managed Service accounts. It seems it only returns the service accounts which are created and not the Google Managed default accounts.
How can I set IAM Policy to grant these permissions to Cloud Build?
The general idea is to enable these permissions for both App Engine and Cloud Run.
Also, a common problem is not knowing that cron permissions are needed for App Engine and Cloud build. For example, this article mentions "Update cron schedules" as "No" for "App Engine Admin". Whether you need that or not depends on how your builds are done. If you end-up needing that too, use permission "Cloud Scheduler Admin" on your #cloudbuild.gserviceaccount.com. You can apply the same logic to other permissions and that chart might be useful for knowing what is needed depending on your setup.