Я пытаюсь найти решение, чтобы предоставить внешнему работнику доступ к экземпляру в нашем проекте, но не ко всем ресурсам.
Я провел небольшое исследование и нашел два метода, как это сделать.
Сначала нужно предоставить подрядчику закрытый ключ для ssh в выбранном экземпляре.
Но я хотел бы попробовать использовать другой метод, который заключается в назначении роли пользователя учетной записи службы для подрядчика.
Насколько я понимаю со служебными аккаунтами. Они объявляются и как ресурс, и как личность. Мне пришлось бы создать новый экземпляр под недавно созданной учетной записью службы с ограниченными определенными разрешениями.
[сервисный аккаунт] >>> разрешения >>> [экземпляры]
[пользователь] >>> роль пользователя учетной записи службы >>> [учетная запись службы]
поэтому я думаю, что роль пользователя учетной записи службы похожа на прокси для учетной записи службы. Я попытался назначить разрешения учетной записи службы и назначил пользователю роль пользователя учетной записи службы. Я бы подумал, что после того, как это будет сделано, пользователю будут назначены разрешения для учетной записи службы. Но, к сожалению, это не так, и мне нужна помощь.
Использование закрытого ключа, как вы предложили, было бы здесь идеальным решением, поскольку это единственный способ убедиться, что у вашего подрядчика не будет доступа к другим экземплярам или информации о статусе вашего проекта. Тем не менее, то, что вы описали (SSH в машину с использованием учетной записи службы) можно сделать, и действительно, учетные записи служб являются одновременно удостоверением и ресурсом.
Если вы дадите пользователю Service Account User
роль для учетной записи службы с необходимыми разрешениями на SSH на машину, которая позволит пользователю делать именно это. Однако имейте в виду, что минимальный набор разрешений, который потребуется этой учетной записи службы для того, чтобы это работало, позволит учетной записи службы (и, следовательно, пользователю тоже) подключаться по SSH к любому экземпляру Compute. Одно это уже свидетельствует о том, что это не даст вам той детализации, которую вы, кажется, хотите.
Чтобы сценарий, который вы создали, был возможен, вам необходимо сделать следующее:
Service Account User
роль и 4 детальных разрешения, compute.instances.get
, compute.instances.setMetadata
, compute.projects.get
, и compute.zoneOperations.get
(вам, вероятно, следует создать собственную роль для этих разрешений). Это можно сделать в разделе IAM и администратора Приставка;Compute Viewer
роль;gcloud compute ssh SERVICE_ACCOUNT_USERNAME@INSTANCE_IP_OR_HOSTNAME --zone ZONE_OF_INSTANCE
.Я бы посоветовал подключить пользователя SSH к целевой машине через Cloud Shell, так как это избавит вас от необходимости выполнять шаг 3 в целом. Не забывайте также о правилах брандмауэра, поскольку общедоступные IP-адреса, назначенные Cloud Shell, похоже, не подпадают под общие диапазоны общедоступных IP-адресов Google.
Не удивляйтесь, если вы увидите сообщение вроде Updating project ssh metadata...failed
. Этого следовало ожидать, поскольку учетная запись службы имеет разрешения только на добавление ключей SSH в метаданные экземпляров.