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.
Related
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.
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.
I have multiple projects in my GCP.
So, for Project A I have created a service account and I am using this service account for Project B using IAM roles and creating various infrastructures.
I am creating these resources using terraform scripts.
As terraform needs service account credentials, I have generated the same key ring JSON file from the Project A and provide in the terraform variable.
The issues occurs when I am creating a Cloud Build Trigger in Project B using terraform, it says it doesn't have enough permissions to create the same, but I have provided all the necessary permissons to do so.
The weird thing what I found that, on the terraform error, it points out to the Project A instead of Project B and i.e. why I am experiencing this error.
The service account key contains project id as well as the the service account name, which in my case is Project A, and that's what creating the issue here.
So, is there any solution for the same, so either in any way I can replace the values in JSON file with the values provided in the scripts.
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 have two GCP projects, A and B, and I want to create a cluster in project B with a node pool also in project B running as a service account in project A.
I am able to create the cluster but when I try to create the node pool I get the following error:
The user does not have access to service account: gke-node#project-A.iam.gserviceaccount.com. Ask a project owner to grant you the iam.serviceAccountUser role on the service account.
I have given project B's Kubernetes Agent Service Account (service-<project-B-number>#container-engine-robot.iam.gserviceaccount.com) the iam.serviceAccountUser role in project A for gke-node#project-A.iam.gserviceaccount.com but this didn't seem to work.
Is this possible to do?
I post this community wiki answer to provide more visibility of the solution provided at the comment section. Feel free to change or expand.
As it was suggested by #Gari Singh you should follow the documentation. The root cause of an issue accordingly to #dippynark was that the iam.disableCrossProjectServiceAccountUsage constraint is enabled. Here you can find more details.