I know you can allow members to impersonate service accounts in GCP. Is it possible to allow one service account to impersonate another?
My use case is I have compute instances used for CI (running without many privileges) under service-account-a#mydomain.google.com.
I need them to be able to impersonate service-account-b#mydomain.google.com, which has privileges on the resources and objects it will deploy.
Is that possible?
Yes, you can grant permission for a service account (SA_A) to impersonate another service account (SA_B).
This requires that the service account (SA_A) possess the Service Account Token Creator role roles/serviceAccountTokenCreator on the resource SA_B.
The following grants SA_A to impersonate SA_B:
gcloud iam service-accounts add-iam-policy-binding [SA_B_FULL_EMAIL] \
--member serviceAccount:[SA_A_FULL_EMAIL] \
--role roles/iam.serviceAccountTokenCreator
REQUIREMENTS
The user executing the above command requires a number of items:
The following APIs must be enabled:
iamcredentials.googleapis.com
cloudresourcemanager.googleapis.com
These commands enable the APIs:
gcloud services enable iamcredentials.googleapis.com
gcloud services enable cloudresourcemanager.googleapis.com
The user requires the role roles/serviceusage.serviceUsageConsumer.
gcloud projects add-iam-policy-binding [PROECT_ID] \
--member "[ACCOUNT]" \
--role "roles/serviceusage.serviceUsageConsumer"
gcloud iam service-accounts add-iam-policy-binding
Google Cloud – Improving Security with Impersonation
Managing service account impersonation
Related
I have service account SA1 which is created in project1 with permission ( cloud function invoker, service account user ). i want to deploy a cloud function CF1 in project2 and specify SA1 in that cloud function as SERVICE_ACCOUNT parameter. while deploying CF1 in project2 i am getting below error even though "service account user" permission exist for this SA1 in project 1 and
SA1 is also added in project 2
ERROR: (gcloud.functions.deploy) ResponseError: status=[403], code=[Ok], message=[Missing necessary permission iam.serviceAccounts.act As
for cloud-functions-mixer on the service account SA1.
Grant the role 'roles/iam.serviceAccountUser' to cloud-functions-mixer on the service account SA1.
It's absolutely not clear and it's a great question!
You need 2 things
Firstly, run the proposed command
gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT --member=cloud-functions-mixer --role=roles/iam.serviceAccountUser
BUT what is that cloud-functions-mixer?? In fact, it's only the account that runs the command
#for you
gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT --member=user:<your email> --role=roles/iam.serviceAccountUser
# for a service account (CI/CD pipeline for instance)
gcloud iam service-accounts add-iam-policy-binding SERVICE_ACCOUNT --member=serviceAccount:<service account email> --role=roles/iam.serviceAccountUser
Then activate the cross-project project usage, deactivated by default. You can achieve that only if you have an organisation. If you haven't, you can't go to organisation policies
Go to Organization policies
Look for Disable Cross-Project Service Account Usage
Edit, click on customize and add rule to disable the rule
I'm looking into roles in GCP. I have a use case to read everything in GCP. So when I looked at the viewer role, docs say it is a read-only role but it seems it has a lot of restrictions. what are the exact permissions of a viewer role?
To list the permission that a role contains, use the CLI:
gcloud iam roles describe roles/editor
gcloud iam roles describe
Editor is a predefined role that currently has 4,078 permissions. Google Cloud manages the permissions for predefined roles. This means that the permissions assigned to these roles can change over time.
You can use the below gcloud commands for roles/viewer.
gcloud iam roles describe roles/viewer
You can add or revoke a single role using the gcloud command-line tool's add-iam-policy-binding and remove-iam-policy-binding commands.
Granting access:
To quickly grant a role to a member, run the following gcloud ‘add-iam-policy-binding’ command:
gcloud projects add-iam-policy-binding my-project --member=user:my-user#example.com --role=roles/viewer
gcloud projects add-iam-policy-binding my-project --member=user:my-user#example.com --role=roles/editor
Revoking access:
gcloud projects remove-iam-policy-binding my-project --member=user:my-user#example.com --role=roles/viewer
For more information, you can also refer to gcloud iam roles describe, roles Granting changing and revoking access to resources.
You should also bare in mind the concept of 'convenience values' that apply to Basic Roles.
In the case of the Viewer role, by default an identity granted this role would be granted more permissions than are listed when running the gcloud command;
gcloud iam roles describe roles/viewer
In addition to the listed permissions, they will be able to read all objects under the resource that the role is granted at through convenience values - see this link to the Google documentation. For example, roles/storage.legacyObjectReader or READER on the bucket ACL will be granted by default (this is dependant on if Uniform Bucket Level Access is configured).
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 created a specific service account in GCP for provisioning clusters in my project :
gcloud iam service-accounts create [sa_name]
gcloud projects add-iam-policy-binding \
[project_id] \
--role=roles/container.admin \
--member=serviceAccount:[sa_name]#[project_id].iam.gserviceaccount.com
gcloud iam service-accounts keys create [keyfile_name] \
--iam-account=[sa_name]#[project_id].iam.gserviceaccount.com
gcloud auth activate-service-account --key-file=[keyfile_name]
When I run the command gcloud container clusters create [cluster_name]
I always get :
ERROR: (gcloud.container.clusters.create) ResponseError: code=403,
message=Required "container.clusters.create" permission(s) for
"projects/context-platform-staging". See
https://cloud.google.com/kubernetes-engine/docs/troubleshooting#gke_service_account_deleted
for more info.
As you can see, I use roles/container.admin but I even tried to apply the roles/editor and roles/owner to this service account, same behavior.
The only way this command works so far is to use my main google owner account (not a service account).
What am I missing here ?
From the error message, I understood that the service account does not have the permission "container.clusters.create".
Please add the "Container Engine Cluster Admin" and also "Container Engine Admin" roles on the service account that the cluster is being created with:.
To create a cluster, you need both "container.clusters.create" permission on the project. You also need to assign the role “roles/iam.serviceAccountUser” to the user who will use the service account. In this way, the user can access GKE's service account.
For more information and in-depth tutorial, please refer to this article in the GCP documentation.
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.