I have a impersonated a Service Account in gcloud through the command gcloud config set auth/impersonate_service_account [SA_FULL_EMAIL].
Now, all my API calls are impersonating the Service Account., is there a way to download the Service Account JSON at this point?
Because I do not have the original Service Account JSON that was created earlier and also as an User I do not have permissions to Manage Keys for this Service Account.
Please let me know, if I can download the Service Account JSON from gcloud by impersonating the Service Account.
Thanks in advance!
I do not have permissions to Manage Keys for this Service Account
Without those permissions, you cannot create or download service account JSON keys. If the service account has those permissions, which it should not for security reasons, then yes.
The following command will create a new JSON key and download it:
gcloud iam service-accounts keys create my-service-account.json --iam-account <EMAIL ADDRESS>
Related
The documentation for the Service Account User role is a bit confusing.
https://cloud.google.com/iam/docs/service-accounts#user-role
Users granted the Service Account User role on a service account can use it to indirectly access all the resources to which the service account has access. For example, if a service account has been granted the Compute Admin role (roles/compute.admin), a user that has been granted the Service Account Users role (roles/iam.serviceAccountUser) on that service account can act as the service account to start a Compute Engine instance. In this flow, the user impersonates the service account to perform any tasks using its granted roles and permissions.
Based on this, I assume that by granting my account the Service Account User role on a service account that is owner, I should be able to impersonate that service account from the command line and run gcloud commands with the inherited permissions of the service account
gcloud init # login to my account that has the user role on the SA
gcloud set config auth/impersonate_service_account <service-account-email>
gcloud compute instances list
> WARNING: This command is using service account impersonation. All API calls will be executed as [<service-account>#<project>.iam.gserviceaccount.com].
> ERROR: (gcloud.compute.instances.list) Failed to impersonate [<service-account>#<project>.iam.gserviceaccount.com]. Make sure the account that's trying to impersonate it has access to the service account itself and the "roles/iam.serviceAccountTokenCreator" role.
So I removed the User role and assigned myself the Token Creator role. Works as expected. Why does the description for the User role sound like its the role I'm meant to be using but it seems like Token Creator is the only one I need?
So despite the confusion of the GCP docs, I think I was able to reach a conclusion on the difference between:
Service Account User
Service Account Token Creator
As an example, if I wanted to deploy a GKE cluster but specify a service account for the nodes to use other than the default service account I would add the flag:
gcloud containers cluster create my-cluster --service-account=<service-account>
For me to do this I would at a minimum require Service Account User on the service account I am attempting to assign to the resources. This role appears to also be used in other cases such as executing code on a VM and using the VMs identity instead(??).
If I wanted to deploy the cluster using the service account credentials (ie. Not my own account), I would use impersonation which requires the Token Creator role. I might want to do this because my personal account doesn't have permission to deploy clusters but the SA does.
gcloud containers cluster create my-cluster --impersonate-service-account=<service-account>
This would build the cluster and log the action as that of the service account, not my personal account.
Please correct me if I'm wrong.
I have an storage bucket that I created on GCP. I created the bucket following the instructions described here (https://cloud.google.com/storage/docs/creating-buckets). Additionally, I created it using uniform bucket-level access control.
However, I want the objects in the bucket to be accessible by instances running under a certain service account. Although, I do not see how to do that. In the permissions settings, I do not see how I can specify a service account for read-write access.
To create a service account, run the following command in Cloud Shell:
gcloud iam service-accounts create storage-sa --display-name "storage service account"
You can grant roles to a service account so that the service account can perform specific actions on the resources in your GCP project. For example, you might grant the storage.admin role to a service account so that it has control over objects and buckets in Google Cloud Storage.
gcloud projects add-iam-policy-binding <Your Project ID> --member <Service Account ID> --role <Role You want to Grant>
Once role is granted you can select this service account while creating the instance.
Alternatively, to do this via Google Cloud Console see Creating and enabling service accounts for instances
Once you have created your service account, you can then change/set the access control list (ACL) permissions on your bucket or objects using ths gsutil command.
Specifically:
gsutil acl set [-f] [-r] [-a] file-or-canned_acl_name url...
gsutil acl get url
gsutil acl ch [-f] [-r] <grant>... url...
where each <grant> is one of the following forms:
-u <id|email>:<perm>
-g <id|email|domain|All|AllAuth>:<perm>
-p <viewers|editors|owners>-<project number>:<perm>
-d <id|email|domain|All|AllAuth|<viewers|editors|owners>-<project number>>:<perm>
Please review the following article for more depth and description:
acl - Get, set, or change bucket and/or object ACLs
You can also set/change acls through the Cloud Console web interface and through GCS API.
You have to create a service account Creating a new service account.
Set up a new instance to run as a service account Set instance.
In the Google Cloud Console go to Storage/bucket/right_corner dots/Edit bucket permissions
Add Member/servive account/
Role/Storage Admin
I have a compute instance in project project-b, and a separate project project-a. The instance in project-b needs to access project-a using a project-a service account.
In project-a:
Create the service account. Suppose its name is project-a-service-account#project-a.iam.gserviceaccount.com.
Grant the service account very specific, limited roles
Create and download a key for the service account. Name it key.json.
In project-b:
Create a compute instance
SSH to the instance. Type all the commands that follow into this compute instance SSH shell.
Upload key file key.json to the instance. If you are using the Google Cloud Console SSH window, you can do this using Upload in the gear icon menu in the upper right.
Activate the service account:
gcloud auth activate-service-account project-a-service-account#project-a.iam.gserviceaccount.com --key-file key.json
Reinitialize:
gcloud init
The gcloud init command will offer to re-initialize the current configuration, or create a new one. It might be nice to create a new one, but it's up to you.
Choose account project-a-service-account#project-a.iam.gserviceaccount.com
Now, this instance in project-b can act as the service account in project-a. For example, if the service account has compute.instances.create permission, you can create an instance in project-a:
gcloud compute instances create new-instance --project project-a
Administrators of project-a can revoke this access by revoking the keys for service account project-a-service-account#project-a.iam.gserviceaccount.com.
Google has a super fast-talking demo showing this.
I'm having trouble getting gcloud to access my project as a service account
Installed the gcloud sdk for Windows on my local machine
Created a new service account on Google Cloud Platform console
Gave the service account the Compute Admin role
Authorized gcloud as the service account:
gcloud auth activate-service-account --key-file=keyfile.json
Issued the command
gcloud compute zones list
I get the following error:
ERROR: (gcloud.compute.zones.list) Some requests did not succeed:
- Required 'compute.zones.list' permission for '<project id>'
I verified the Compute Admin role has the proper compute.zones.list permission.
What am I missing?
I fixed the issue by recreating the service account.
It seems there's a screen that asks about the roles you want the service account to have as you create it. I originally assigned the roles after the fact.
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.