v1.compute.instances.setMetadata and instances configured with service account

1,372 views
Skip to first unread message

Aleksei Feltin

unread,
Jan 6, 2022, 1:01:42 PM1/6/22
to gce-discussion
Hi,

This has been unclear to me as how instance metadata is updated for the instance NOT configured with any SA. 

In my scenario I created 2 VM instances, both with OS-login disabled:

Instance A: using default compute service account
Instance B: not associated with any service account

I am using gcloud compute ssh to initiate ssh connection

In order to successfully connect to instance A I need to grant my principal the role roles/iam.serviceAccountUser

This role is not required for connecting to Instance B. I was wondering if it's something to do how metadata update is authorized in the GCE? Does it internally defaults to a VM's service account to perform it, and if no VM SA account is setup, then it uses principal directly? I could not really figure this out examining http methods/audit logs as it all looked method v1.compute.instances.setMetadata, which was invoked by my principal failed for Instance A without granting the role roles/iam.serviceAccountUser and always succeeded for Instance B.

Just curious to understand what exactly is taking place here.

Rgards,
A

mbazzi

unread,
Jan 6, 2022, 4:22:46 PM1/6/22
to gce-discussion
Hello,

For Instance A, the role roles/compute.instanceAdmin.v1 is sufficient to allow SSH connection to the instance using the gcloud tool or SSH from the Browser. The role roles/iam.serviceAccountUser is used to run operations as a service account (impersonation) and is not needed to SSH to a GCE instance.

Are you able to provide us of the generated error you are encountering when attempting to SSH into instance A without the role roles/iam.serviceAccountUser.

Aleksei Feltin

unread,
Jan 7, 2022, 12:28:28 PM1/7/22
to gce-discussion
I don't believe it's sufficient @mbazzi, and I think it's related to the fact that default compute service account, or any service account, if configured with the instance, is used to push keys to the instance metadata.

In my test user, who is invoking 'gcloud compute ssh' is already granted roles/compute.instanceAdmin.v1

Without roles/iam.serviceAccountUser role binding:

$ gcloud compute ssh test-vm-02
Updating project ssh metadata...failed.
Updating instance ssh metadata...failed.
ERROR: (gcloud.compute.ssh) Could not add SSH key to instance metadata:
 - The user does not have access to service account '1220045221...@developer.gserviceaccount.com'.  User: 'jd...@acme.com'.  Ask a project owner to grant you the iam.serviceAccountUser role on the service account

After creating a binding, it works

$ gcloud iam service-accounts add-iam-policy-binding 105769910040773408142 --member='user:jd...@acme.com' --role='roles/iam.serviceAccountUser'

$ gcloud compute ssh test-vm-02
Updating project ssh metadata...failed.
Updating instance ssh metadata...⠛Updated [https://www.googleapis.com/compute/v1/projects/playground-337303/zones/asia-southeast1-b/instances/test-vm-02].
Updating instance ssh metadata...done.
Waiting for SSH key to propagate.
Warning: Permanently added 'compute.8169197730585635041' (ECDSA) to the list of known hosts.
Linux test-vm-02 4.19.0-18-cloud-amd64 #1 SMP Debian 4.19.208-1 (2021-09-29) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Reply all
Reply to author
Forward
0 new messages