Как пользоваться CLI при авторизации через Google?
Коллеги, пните в нужную сторону.
настроил SAML 2.0 Federated Users с GSuit, пользоватли замечательно логинятся в консоль со своим гугловым аккаунтом. Но внезапно встал вопрос - а как тогда получить креды для консоли?
Дополнительно:
Ответы:
Идти в IAM и генерировать пользователям креды для cli. И разрешать им, соответственно, этот вид доступа.
- Без 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 keysecret key и следить за тем что они регулярно меняются - это проблема для любого человека. С точки зрения безопасности заводить и следить за тем, что все регулярно обновляют свои креды - тот еще геморрой.
Гораздо более корректно - выписывать временные креды через соответствующие интерфейсы. Креды, которые гарантированно устареют и ты на это никак не повлияешь. Креды, которые не надо чистить - они сами удаляются. Креды, которые генерятся человеку, а не сервисному аккаунту, что исключает необходимость держать их постоянно.
Временные креды - решение. С гугловой авторизацией их сгенерить, чтобы не приходилось вычищать - проблема, хотя и (через задницу) решаемая. С реализацией в AWS SSO - тебе напрямую выдают временные креды соответствующие твоей роли. Это очень удобно, мы сейчас заняты вычищением всего того дерьма, что нагенерили жалкие 30 пользователей AWS за два года. CLI креды 450 дней от роду, "очень нужные". - Евгений, и все эти проблемы решаются вообще через другое место по тому что лечите как всегда следствие, а не причину)
- Иван Шумов, ну конечно, вам виднее :D
- Евгений, скорее опыт)
того дерьма, что нагенерили жалкие 30 пользователей
означает только то что кто-то плохо в мониторинг, полиси и ротацию. не говоря уже о процессах, конечно
Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.
Пока нет других ответов. Будьте первым, кто поможет автору.
Ответить на вопрос
Для авторизации через Google с помощью CLI (Command Line Interface) можно воспользоваться утилитой OAuth 2.0 и Google API. Ниже приведен пример использования PHP для авторизации через Google CLI:
1. Создайте проект на Google Cloud Platform и включите в нем Google API.
2. Установите библиотеку Google API Client для PHP с помощью Composer:
composer require google/apiclient
3. Создайте файл `authorize.php` и добавьте следующий код:
setAuthConfig('path/to/your/credentials.json');$client->setScopes(['https://www.googleapis.com/auth/userinfo.email']);
// Если необходимо авторизоваться снова, раскомментируйте эту строку
// $client->setAccessType('offline');
$authUrl = $client->createAuthUrl();
echo "Авторизуйтесь по следующей ссылке: