I wasn't able to add a new member in GCP (IAM) with the role owner using the gcloud command
The below command fails:
gcloud projects add-iam-policy-binding linuxacademy-3 --member user:rohithmn3#gmail.com --role roles/owner
With the below Error/Exception:
ERROR: (gcloud.projects.add-iam-policy-binding) INVALID_ARGUMENT: Request contains an invalid argument.
- '#type': type.googleapis.com/google.cloudresourcemanager.v1.ProjectIamPolicyError
member: user:rohithmn3#gmail.com
role: roles/owner
type: SOLO_MUST_INVITE_OWNERS
But, the same command works well for other roles like: viewer, browser...! It just doesn't work for "owner".
Is there any alternative for this; if yes, How to add this in my Python Code.
Please help me here..!
Regards,
Rohith
You cannot grant the owner role to a member for a project using the Cloud IAM API or the gcloud command-line tool. You can only add owners to a project using the Cloud Console. An invitation will be sent to the member via email and the member must accept the invitation to be made an owner of the project, Documentation
Related
Background
By default, Cloud Run uses the Compute Engine default service account which grants a broad range of permissions which are not required by the container that I'm trying to run in it, and as a result I'd like to set up a new service account.
If I understand correctly, I'd need to do the following:
Create a role with the desired set of permissions (using gcloud iam roles create)
Create a service account (using gcloud iam service-accounts create)
Bind the role permissions to the service account.
Deploy an image with the service account set up in step 2 (using gcloud run deploy --service-account).
The aforementioned documentation doesn't mention how to achieve step 3. I found the gcloud iam service-accounts add-iam-policy-binding command, but I see this is a three way binding between an user (member), a service account and a role, whereas what I've described above seems to require only a two-way binding with the permission grant to the Cloud Run service occurring in the fourth step.
Questions
Do I have the right understanding with regards to the steps required to set up a custom service account for Cloud Run to use?
Assuming I have understood this correctly, what would be the correct way to set up the binding of permissions with the service account?
You can use a custom role in addition of user managed service account, but it's not mandatory. You can also create a user managed service account and bind it with predefined roles.
Anyway, if you want to bind a custom role to a service account (or a user account, no difference), you have to use the fully qualified path for the role
# Project level
projects/<projectID>/roles/<custom role name>
# Organization level
organizations/<organizationID>/roles/<custom role name>
And the gcloud command can be this one
gcloud projects add-iam-policy-binding <projectID> \
--member=serviceAccount:<service account email> \
--role=projects/<projectID>/roles/<custom role name>
I'm creating a sink by running the following command (as an organization administrator):
gcloud logging sinks create vpc_flow_sink storage.googleapis.com/<storage_bucket_name> --include-children --organization=<organization_id> --log-filter="resource.type="gce_subnetwork" AND logName:"logs/compute.googleapis.com%2Fvpc_flows""
The command executes successfully and outputs the following text:
Created [https://logging.googleapis.com/v2/organizations/<organization_id>/sinks/<sink_name>].
Please remember to grant serviceAccount:o<organization_id>-511237#gcp-sa-logging.iam.gserviceaccount.com the Storage Object Creator role on the bucket.
However, when I go to actually apply the permission to the storage bucket, I cannot find this account (in either the project or within the organization). The accounts also do not appear when I run:
gcloud organizations get-iam-policy <organization_id>
When I describe the sink, the service account exists within the writerIdentity field:
gcloud beta logging sinks describe vpc_flow_sink --organization <organization_id>
...
writerIdentity: serviceAccount:o<organization_id>-511237#gcp-sa-logging.iam.gserviceaccount.com
...
For reference, to try debug this issue, I've attached the following roles: Organization Role Administrator, Logging Admin, Owner, Project Owner, Organization Administrator, Storage Admin.
I am genuinely lost on what to do, how do I go about granting the bucket the role to this account?
When applying the permission to you export destination, don't copy:
serviceAccount:o<organization_id>-511237#gcp-sa-logging.iam.gserviceaccount.com
but instead just use everything after serviceAccount:
o<organization_id>-511237#gcp-sa-logging.iam.gserviceaccount.com...
Google will then recognize the service account. However, I still cannot detect it via gcloud organizations get-iam-policy <organization_id>
I want to grant a service account access to a secret in Google Secrets Manager.
I can access the secret like this:
gcloud beta secrets versions access 1 --secret="thesecret" --project="myproject"
But when my service account tries the same command, gcloud emits this error:
ERROR: (gcloud.beta.secrets.versions.access) PERMISSION_DENIED: Request had insufficient authentication scopes.
The main question is: What else do I need to do to ensure that the service account can access the secret?
I have granted that service account "roles/secretmanager.secretAccessor" in Terraform like this:
resource google_project_iam_binding the-binding {
project = myproject
role = "roles/secretmanager.secretAccessor"
members = [
"serviceAccount:theserviceaccount#someotherproject.iam.gserviceaccount.com",
]
}
And I can verify that it has that role both in the gcp console and like this:
gcloud projects get-iam-policy myproject \
--flatten="bindings[].members" \
--format='table(bindings.role)' \
--filter="bindings.members:theserviceaccount#someotherproject.iam.gserviceaccount.com"
ROLE
roles/secretmanager.secretAccessor
But there's this concept from the docs:
If a member only needs to access a single secret's value, don't grant that member the ability to access all secrets. For example, you can grant a service account the Secret Accessor role (roles/secretmanager.secretAccessor) on a single secret.
So it's like an iam-policy-binding can have an affinity to a particular secret, but I'm not sure which gcloud commands or terraform resources I can use to create such an affinity.
The first problem is that I was mistaken about which service account my environment was configured to use. So I had granted access to the service account, but I wasn't using it after all (apparently they're initialized inconsistently in my case). I fixed that by running this command before trying to access the secret:
gcloud config set account theserviceaccount#someotherproject.iam.gserviceaccount.com
Also, I didn't realize that there were more than one toplevel gcloud command that let you modify iam policy bindings. I had been exploring gcloud iam ... when what I needed was:
gcloud beta secrets add-iam-policy-binding projects/myproject/secrets/mysecret --member serviceAccount:theserviceaccount#someotherproject.iam.gserviceaccount.com --role roles/secretmanager.secretAccessor
I'm following the Google GKE and SQL with terraform tutorial
But I'm not able to create a google_project.project.
I have tried both as the owner of the project and as the service described in the tutorial. Both attempts end with this error:
Error: Error applying plan:
1 error(s) occurred:
* google_project.project: 1 error(s) occurred:
* google_project.project: error creating project terraform-dev-357aa670
(terraform-dev): googleapi: Error 403: User is not authorized., forbidden.
If you received a 403 error, make sure
you have the `roles/resourcemanager.projectCreator` permission
I would think that I had the correct permissions as the project owner, but apparently not.
Here's how I created the service account:
$ gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \ (gke_my-domain-218910_europe-west1-b_my-domain-vpc-native/default)
> --member serviceAccount:terraform#${TF_ADMIN}.iam.gserviceaccount.com \
> --role roles/resourcemanager.projectCreator
Updated IAM policy for organization [00000].
bindings:
- members:
- domain:my-domain.no
role: roles/billing.creator
- members:
- serviceAccount:terraform#my-domain-terraform-admin-3.iam.gserviceaccount.com
- serviceAccount:terraform#my-domain-terraform-admin.iam.gserviceaccount.com
role: roles/billing.user
- members:
- domain:min-familie.no
- serviceAccount:terraform#my-domain-terraform-admin-3.iam.gserviceaccount.com
- serviceAccount:terraform#my-domain-terraform-admin.iam.gserviceaccount.com
role: roles/resourcemanager.projectCreator
etag: BwWJxJTDnQs=
version: 19d
Creating a project "manually" works.
$ gcloud projects create ${TF_ADMIN}.
Any ideas what might be wrong?
In order to create folders and projects, your account need to have the respective permissions and, of course you need to make sure that you are using the right account.
First make sure the user has the right permissions:
gcloud organizations add-iam-policy-binding YOUR_ORGANIZATION_ID --member=user:your#email.com --role=roles/billing.admin
gcloud organizations add-iam-policy-binding YOUR_ORGANIZATION_ID --member=user:your#email.com --role=roles/resourcemanager.organizationAdmin
gcloud organizations add-iam-policy-binding YOUR_ORGANIZATION_ID --member=user:your#email.com --role=roles/resourcemanager.folderCreator
gcloud organizations add-iam-policy-binding YOUR_ORGANIZATION_ID --member=user:your#email.com --role=roles/resourcemanager.projectCreator
Then make sure you set the application defaults and login to exactly this account:
gcloud auth application-default login
The set a project that the API calls will be billed to by default. Read more about this here. If you don't set this, you might get a quota error when you run terraform apply.
gcloud auth application-default set-quota-project SOME_BILLING_PROJECT
I had exact same problem!
Steps that solved this problem for me:
Downloaded the key for that Service Account (Using GCP Console) to : /Users/johndoe/sa.json
export GOOGLE_APPLICATION_CREDENTIALS=/Users/johndoe/factory.json
terraform apply
Hope this works for you.
Found the solution from Seth Fargo here:
https://github.com/sethvargo/vault-on-gke/issues/16
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.