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.
Related
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.
I am trying to add a service account to my cloud run service. However, there is a message that "No service account with required permissions available."
I'm not sure if this is related to my user's credentials, or something else. This project has the default compute service account, as well as additional service accounts.
I can't find anything related in the documentation regarding this.
Would appreciate any insight you have on this issue!
Yes, I think that's probably (!?) what's occurring.
I assume that you're using Cloud Console and trying to Create a Cloud Run service.
I was able to add a minimally-roled user to an existing project and, when trying to create a Cloud Run service, I observe the same behavior that you're seeing.
How do you know that the project contains Service Accounts? I assume that your permissions are similarly restricted in eumerating these.
The permissions required to set a service account are described here. You need service account user permissions on the project or specific service account in order to set it on a deploy.
We have two projects in our GCP account; one for our Dev environment and one for our Test environment at the moment. Terraform manages most of our infrastructure, so we have minimal clicking around the GUI, or CLI commands.
I have assumed we enabled the Pub/Sub API by deploying to it with Terraform in both of our environments, although we may have needed to do this manually. We noticed that Google created a default Pub/Sub service account for us in our Dev environment, but not in our Test environment. This docs page suggests it should make this service account.
Additionally, we have noticed multiple Pub/Sub subscriptions working, apparently without any service account. We believe that the service account is only needed for this particular Subscription because it is a push to an e-mail server. Therefore, it needs a service account with the 'Service Account Token Creator' role.
We've attempted to redeploy the whole infrastructure and disable/re-enable the Pub/Sub API. Neither seemed to kick GCP into creating the Service Account. Further to this, we attempted to make the default service account manually. Still, GCP constrains the name a user can give a service account themselves, so we're unable to create a service account with the name that the Pub/Sub service would expect.
We wonder if there is some configuration of the project we may have missed or if anyone has seen this previously?
Does it not exist or does you not see it?
I'm pretty sure that it exists but without any role granted on it and you don't see it in the UI. Try to grant a role on this default service account, and it will appear in the IAM page!
I have a small python app running in google cloud run with docker. The application is triggered by http requests, executes a query in big query and return the result. Unfortunately I get the following permission error:
Reason: 403 POST https://bigquery.googleapis.com/bigquery/v2/projects/XXXX/jobs: Access Denied: Project XXXX: User does not have bigquery.jobs.create permission in project XXXX.\n\n(job ID: XXXX-XX-XX-XX-XXXX)\n\n
I understand I need to give access from cloud run to big query. How do I do it? to which user? how can i find out?
You need to add BiqQuery permissions via IAM Roles to the service account assigned to Cloud Run.
To allow Cloud Run to create Big Query jobs (bigquery.jobs.create) you need one of the following roles:
roles/bigquery.user
roles/bigquery.jobUser
The service account for Cloud Run is displayed in the Google Cloud Console in the Cloud Run section for your service. Most likely this is Compute Engine default service account.
To add a BiqQuery role, you can use the Google Cloud Console. Go to IAM, find the service account. Add roles to the service account.
Documentation:
BigQuery predefined Cloud IAM roles
Service accounts on Cloud Run (fully managed)
Granting roles to service accounts
One of the issues could be that Service Account which your Cloud Run job is using does not have permissions on BigQuery.
You can update the service account permission and add roles/bigquery.user role to create a job.
Also, based on your application requirement add relevant roles. You can see details about different BigQuery roles here.
A good rule is provide only required permissions to a service account.
I hope this helps.
The application is triggered by http requests, executes a query in big query and return the result.
From the security standpoint the permissions required are identical to those used by the custom website from this solution. I'm the author. The website is also triggered by http requests, executes a query in BQ and returns the result. And granting the permission to create jobs (via bigquery.jobUser role) is not enough.
You can grant the required permissions to the service account in different ways (e.g. a more sweeping permission and a more restricted one), the details are here at the Step 6.
Generally speaking, the more restricted and the more granular the permissions are the better for security.
I'm adding extra clarifications and also pasting specific instructions related to Google's tools usage.
To add the permission to create and run jobs (the BQ error message says this permission is lacking) execute the command:
gcloud projects add-iam-policy-binding <project-name> --member=serviceAccount:<sa-name>#<project-name>.iam.gserviceaccount.com --role roles/bigquery.jobUser
The command can be executed in Cloud Shell, open it using the "Activate Cloud Shell" icon in BigQuery Web UI or from other Google Console page. Replace the placeholders:
<sa-name> - replace with service account name used by Cloud Run,
<project-name> - replace with the project name.
The command adds the role bigquery.jobUser to the service account. Do not add other permissions/roles to solve the inability to create/run jobs because excessive permissions are bad for security.
Another permission is required to read BQ data. There are two options to add it:
Grant the bigquery.dataViewer role to the service account:
gcloud projects add-iam-policy-binding <project-name> --member=serviceAccount:<sa-name>#<project-name>.iam.gserviceaccount.com --role roles/bigquery.dataViewer
Then proceed to the next step. Not recommended unless you are using a throw-away project. The drawback of this approach is granting permissions to view all project datasets.
Take more granular approach (recommended) by allowing the service account to query one dataset only. This is the approach described below.
Execute the commands replacing <ds-name> with the dataset name (used by your query):
bq show --format=prettyjson <ds-name> >/tmp/mydataset.json
vi /tmp/mydataset.json
Using vi, append the following item to the existing access array and replace the placeholders before saving the file:
,
{
"role": "READER",
"userByEmail": "[<sa-name>#<project-name>.iam.gserviceaccount.com](mailto:<sa-name>#<project-name>.iam.gserviceaccount.com)"
}
Execute the command to effect the changes for the dataset:
bq update --source /tmp/mydataset.json <ds-name>
Enabling the Cloud Run API (dev console→Cloud Run→Enable) creates five service accounts. I want to understand their purpose. I need to know if it's my responsibility to configure them for least privileged access.
The Default compute service account has the Editor role. This is the Cloud Run runtime service account. Its purpose is clear, and I know it's my responsibility to configure it for least privileged access.
The App Engine default service account has the Editor role. This matches the description of the Cloud Functions runtime service account. Its purpose is unclear, given the existence of the Cloud Run runtime service account. I don't know if it's my responsibility to configure it for least privileged access.
The Google Container Registry Service Agent (Editor role) and Google Cloud Run Service Agent (Cloud Run Service Agent role) are both Google-managed service accounts "used to access the APIs of Google Cloud Platform services":
I'd like to see Google-managed service accounts configured for least privileged access. I'd also like to be able to filter the Google-managed service accounts in the IAM section of the GCP console. That said, I know I should ignore them.
The unnamed {project-number}{at}cloudbuild.gserviceaccount.com service account has the Cloud Build Service Account role. This service account "can perform builds" but does not appear in the Cloud Run Building Containers docs. It's used for Continuous Deployment—but can't do that without additional user configuration. It's not a Google-managed service account, but it does not appear in the Service Accounts section of the GCP console like the runtime service accounts. Its purpose is unclear. I don't know if it's my responsibility to configure it for least privileged access.
Cloud Run PM:
Yep, exactly right.
We should probably not create this if you're only using Run (and likely not enable the App Engine APIs, which is what created this). During Alpha, this was the runtime service account, and it's likely that it wasn't cleaned up.
I have a feeling it's stuck as Editor because it accesses Cloud Storage, which is oddly broken for "non Editor access" (I'm still trying to track down the exact issue, but it looks like there's a connection to the legacy Editor role that requires it).
Is already "least privileged" from it's perspective, as it only has the permissions to do the things that Run needs to do in order to set up resources on your behalf.
This is the runtime service account equivalent for Cloud Build, and falls into the same category as 1,2. If you need a build to deploy to Cloud Run, you have to grant this account something like Cloud Run Deployer (plus to the additional step of allowing the build service account to act as your runtime service account, to prevent [or at least acknowledge] privilege escalation).
I too want better filtering of "Google created" and "Google managed" and have been talking with the Cloud IAM team about this.