I have 2 projects
Under project 1 :
I have created a service account.
Under project 2 :
I have enable dataflow service API.
I have added the service account(which was created under project 1) with owner role .
Issue
I have authenticated successfully into project 2 using python.
When I try to create, list dataflow services under the project 2
"403 Dataflow API has not been used in project "project1" before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/dataflow.googleapis.com/overview?project=project1 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry."
However I enabled the dataflow API service in project1 and now able to access it under project 2.
Is it that we need to enable the Dataflow API service in project1 in order to use it in project 2 ?Is this how it works? Is there a better way/ right way to solve this?
I don't want to keep enabling service in a project which I don't need to use.
Create a separate service account specifically for Project 2 and grant it the necessary permissions to access the Dataflow service in that project. This way, you would not need to enable the Dataflow API in Project 1.
Alternatively, you could use a Shared VPC setup and give access to a project to another project's service account by adding the service account to the IAM roles of the other project's Shared VPC host project. This way the service account doesn't need to be enabled for the dataflow API in both projects.
Related
We have a use case where project A has some secrets and databases which cannot be moved to another project. We have a project B that uses the secrets and databases from project A.
Project A has a service account X that accesses the secrets and databases.
Project B has a service account Y with no permissions to the secrets and databases. The goal is for service account Y to impersonate service account X during a build trigger connected to pushes to github. Project B has a cloud build pipeline that needs to temporarily access the secrets and database in Project A during the CICD process.
According to this :https://cloud.google.com/build/docs/cloud-build-service-account, section User-specified service account...You can create a custom IAM role with an impersonation permission or use pre-defined roles that allow principals to impersonate a service account.
I create a service account X and gave service account Y permissions to impersonate it (as checked in policy analyzer) however, when I try to use service account X in project B 's cloud run trigger I get (as expected):
Failed to update trigger: generic::permission_denied: user does not have impersonation permission on the trigger service account specified: projects/redacted/serviceAccounts/service#project-A.com
What "user" is this referring to? The one using the console? the build service agent?
Is it possible to get a service account Y in Project B to impersonate service account X in Project A during the build step process?
According to this https://cloud.google.com/build/docs/securing-builds/configure-user-specified-service-accounts ...To use the Triggers page in the Google Cloud console, the user-specified service account and the build trigger must be in the same project.
Is there a workaround for this e.g is it necessary to use gcloud to impersonate the account? Or is there a way to perform cross project account impersonation (for triggers) using the cloudbuild.yaml or somehow tell the trigger that the service account being used must impersonate another?
you have 2 solutions:
Use the service account X from the project A as Cloud Build user managed service account. You have to grant the Cloud Build Service Agent service account the permission to impersonate the service account X in project A. In addition, this service account X must have access to your project B resource also to interact with them. This solution is convenient because you can use the built-in connection with secret manager
Use the current configuration, but perform manual impersonation in the Cloud Build pipeline when you want to get the secrets (with code, not with the Cloud Build built-in integration with secret manager).
I'm trying to create a GKE Cluster through Terraform. Facing an issue w.r.t service accounts. In our enterprise, service accounts to be used by Terraform are created in a project svc-accnts which resides in a folder named prod.
I'm trying to create the GKE cluster in a different folder which is Dev and the project name is apigw. Thro Terraform, when I use a service account with the necessary permissions reside in the project apigw, it works fine.
But when I try to use a service account with the same permissions where the service account resides in a different folder, getting this error
Error: googleapi: Error 403: Kubernetes Engine API has not been used in project 8075178406 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/container.googleapis.com/overview?project=8075178406 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.
where 8075178406 is the project number of svc-accnts
Why does it try to enable the API in svc-accnts when the GKE cluster is created in apigw. Are service accounts not meant to used across folders?
Thanks.
The error you provide is not about permissions of the service account. Maybe you did not change the project in the provider? Remember, you can have multiple providers of the same type (google) that point to different projects. Some code example would provide more information.
See:
https://medium.com/scalereal/how-to-use-multiple-aws-providers-in-a-terraform-project-672da074c3eb (this is for AWS, but same idea)
https://www.terraform.io/language/providers/configuration
Looks like this is a known issue and happens through gcloud cli as well.
https://issuetracker.google.com/180053712
The workaround is to enable the Kubernetes Engine API on the project(svc-accnts) and it works fine. I was hesitant to do that as I thought this might create the resources in the project.
New to GCP and use IAC for our Terraform. I've managed to build most of the initial organisation config in Terraform no problem with the exception of Cloud Identity and Organisation Policies. I'm using gcloud provided login credentials. Whenever I try to build for those two services I get this:
Error creating Group: googleapi: Error 403: Your application has authenticated using end user credentials from the Google Cloud SDK or Google Cloud Shell which are not supported by the cloudidentity.googleapis.com. We recommend configuring the billing/quota_project setting in gcloud or using a service account through the auth/impersonate_service_account setting. For more information about service accounts and how to use them in your application, see https://cloud.google.com/docs/authentication/. If you are getting this error with curl or similar tools, you may need to specify 'X-Goog-User-Project' HTTP header for quota and billing purposes. For more information regarding 'X-Goog-User-Project' header, please check https://cloud.google.com/apis/docs/system-parameters.
So in this case i'm using the Google Cloud SDK, so the error makes sense. However, the two options it presents don't work:
Setting a quota project makes no difference
I can't create a service account at the organisational level (and when I create one within a project it can't configure these organisational level constructs)
So how do I go about Terraforming these services?
Thanks.
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.
We have an issue with a service account 'defaulting' to the project where it was created when enabling APIs before creating resources.
The SA was created under project A but it has Owner rights for project B.
We're trying to create a resource (GKE cluster) in project B but it's complaining we need to enable the Kubernetes API on project A first (we are passing --project to the cluster create command to avoid any ambiguity around where we're trying to create the cluster. this is also the case for the get-credentials command).
ERROR: (gcloud.container.clusters.create) ResponseError: code=403, message=Kubernetes Engine API has not been used in project PROJECT_NUMBER before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/container.googleapis.com/overview?project=PROJECT_NUMBER then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.
PROJECT_NUMBER here is the number of project A, not B. The required API is already enabled on project B.
Is there something flawed in our approach to the use of service accounts here?
Even though you're creating a cluster in project B, the caller of the API is project A (because the service account is owned by project A); therefore, the API must be enabled on project A.