Как пользоваться CLI при авторизации через Google?

Без IAM. Вернее без заведения там пользователей - иначе нафига внешняя авторизация.

Макс, Никак. Можно забыть об этом как класс. AWS имеет всего один тип аутентификации через cli: access key + secret и в ближайшем будущем это менять не планирует

Иван Шумов, однако неправда
тут есть рецепт для винды. Но хочется такого-же, но для линуксов-мака.

Макс, Ну, вообще это именно то что я и говорил. Другого способа аутентификации нет, а в статье - воркэраунд, который перестанет работать после того как креды будут сброшены в IAM. Это просто набор скриптов, которые можно также воспроизвести и на Linux и на osx. По федерации в cli никого не пустит - это отдельные доступы и пермишены, настраиваемые в iam

Тоже не обнаружили удобного способа работы через CLI при использовании Auth через G-Suite. Даже питоновский скрипт писал который через формы вытягивал данные аутентификации гугловые и вбивал в переменные окружения сгенеренные accesskey secretkey и token, но это то еще удовольствие.
Однако, как обычно, не было бы счастья... Родительская компания решила уходить от гугла в microsoft в офисных приложениях.
Вследствие этого пользователи потеряли доступ к гуглу и нам пришлось переизобрести Single Sign On для наших нужд в AWS.

Теперь используем сервис AWS SSO с интеграцией каталога с AD (у нас свой, через AD connector, но можно использовать AWS Managed Microsoft AD) для каталога пользователей. Удобство - колоссальное. Прозрачный маппинг ролей и политик доступа на группы в AD, лёгкое добавление прав, временные (причем время жизни регулируется в политике на стороне AWS) креды для работы - залогинился в SSO, копипастой взял креды, в командную строку вбил и N часов работаешь с ними.
Идеальный сервис, на мой взгляд. К сожалению умеет только каталоги AD на данный момент. Но SSO через интеграцию с гуглом - и рядом не валялся.

Евгений, это работа аутентификации через STS сервис, так называемая) то есть там история что вся аутентификация происходит через него, просто постоянный доступ обеспечивается только через креды в IAM. При логине любым способом пользователь получает STS токен и работает через него) Но все-равно это дикость - ели человеку надо работать с CLI то он прекрасно должен уметь работать с AWS и можно дать ему programmatic access и генерировать себе пары ACCESS KEY/SECRET. В чем вообще проблема-то я не понимаю))

Иван Шумов, Проблема в девопс :D
Любой девелопер должен следить за своим сервисом, в том числе выполнять преподготовленные терраформ модули для публикации своего сервиса\мейнтенанс работ. А для этого нужны CLI креды.
Генерировать access key\secret key и следить за тем что они регулярно меняются - это проблема для любого человека. С точки зрения безопасности заводить и следить за тем, что все регулярно обновляют свои креды - тот еще геморрой.
Гораздо более корректно - выписывать временные креды через соответствующие интерфейсы. Креды, которые гарантированно устареют и ты на это никак не повлияешь. Креды, которые не надо чистить - они сами удаляются. Креды, которые генерятся человеку, а не сервисному аккаунту, что исключает необходимость держать их постоянно.
Временные креды - решение. С гугловой авторизацией их сгенерить, чтобы не приходилось вычищать - проблема, хотя и (через задницу) решаемая. С реализацией в AWS SSO - тебе напрямую выдают временные креды соответствующие твоей роли. Это очень удобно, мы сейчас заняты вычищением всего того дерьма, что нагенерили жалкие 30 пользователей AWS за два года. CLI креды 450 дней от роду, "очень нужные".

Евгений, и все эти проблемы решаются вообще через другое место по тому что лечите как всегда следствие, а не причину)

Иван Шумов, ну конечно, вам виднее :D

Евгений, скорее опыт)

того дерьма, что нагенерили жалкие 30 пользователей

означает только то что кто-то плохо в мониторинг, полиси и ротацию. не говоря уже о процессах, конечно