5

We have a user that is allowed to SSH into an VM on the Google Cloud Platform.

His key is added to the VM and he can SSH using

gcloud compute ssh name-of-vm

However connecting in this way will always have gcloud try to update project wide meta data

Updating project ssh metadata...failed

It fails because he only has rights for accessing & administrating this VM

However it's very annoying that every time he has to connect in this way he has to to wait for GCP trying to update metadata, which is not allowed and then check the sshkeys on the machine.

  1. Is there a flag in the command to skip checking/updating project wide ssh keys?

Yes we can 'block project wide ssh keys' on the instance, but that would mean that other project admins cannot log in anymore.

I've also tried to minimise access to this user.

  1. But, ideally, what rights should he have if he is allowed to SSH to the machine, start & stop the instance and store data into a bucket?
Tom Lous
  • 2,489
  • 1
  • 16
  • 40

2 Answers2

2

What you can do is to enable-oslogin for all the users you need including admins, enabling OS Login on instances disables metadata-based SSH key configurations on those instances.

The role to start, stop and connect via SSH to an instance would be roles/compute.instanceAdmin (take in account that this role is currently in beta) you can check here a list of the Compute Engine roles available so you can choose the one that better suits your needs.

To store data into a bucket, I think the most suitable role is roles/storage.objectCreator that allows users to create objects but not to delete or overwrite objects.

Shibboleet
  • 450
  • 2
  • 12
0

Re: #1: There's no flag on the command to change this behavior on a per-command level instead of a per-instance level ('block-project-ssh-keys', as you mentioned) but you could file a FR at https://issuetracker.google.com/savedsearches/559662.

Kristen Tracey
  • 132
  • 2