Ohmyzsh: Плагин AWS пытается вручную взять на себя роль

Спасибо за ваш доклад. Я исследую и вернусь.

Моя установка:

1. Учетные данные AWS в профиле с использованием asp profilename
2. Использование https://github.com/joepjoosten/aws-cli-mfa-oh-my-zsh для аутентификации с помощью MFA
3. При использовании asp otherprofile (где otherprofile имеет учетные данные role_arn и source_profile ) я получил:

Assuming role arn:aws:iam::9999999999999:role/myrole using profile otherprofile

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::11111111111:user/original_user is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::9999999999999:role/myrole
Switched to AWS Profile: otherprofile

Таким образом, он переключает профиль при сбое

Скрипт, который действительно работает (для идей), если я сделаю aar otherprofile :

aar () {
    if [[ -z "$1" ]]
    then
        unset AWS_DEFAULT_PROFILE AWS_PROFILE AWS_EB_PROFILE
        echo AWS profile cleared.
        return
    fi
    local aws_profile_name=${1}
    local role_arn=$(aws configure --profile ${aws_profile_name} get role_arn)
    if [[ -z "$role_arn" ]]
    then
        echo Role ARN for profile \(${aws_profile_name}\) cannot be found.
        echo Please set the \'role_arn\' attribute on the profile.
        return 1
    fi
    local session_name="${aws_profile_name}-session"
    local credentials_output=$(aws sts assume-role --role-arn ${role_arn} --role-session-name ${session_name} --query '[Credentials.AccessKeyId,Credentials.SecretAccessKey,Credentials.SessionToken]' --output text | tr "\t" "\n")
    local credentials=("${(f)credentials_output}")
    local access_key_id=${credentials[1]}
    local secret_access_key=${credentials[2]}
    local session_token=${credentials[3]}
    aws configure --profile ${aws_profile_name} set aws_access_key_id ${access_key_id}
    aws configure --profile ${aws_profile_name} set aws_secret_access_key ${secret_access_key}
    aws configure --profile ${aws_profile_name} set aws_session_token ${session_token}
    export AWS_ACCESS_KEY_ID=${access_key_id}
    export AWS_SECRET_ACCESS_KEY=${secret_access_key}
    export AWS_SESSION_TOKEN=${session_token}
    export AWS_DEFAULT_PROFILE=${aws_profile_name}
    export AWS_PROFILE=${aws_profile_name}
    export AWS_EB_PROFILE=${aws_profile_name}
    echo Credentials set for AWS profile \(${aws_profile_name}\)
}

Я не возражаю против использования разных функций для MFA и прочего, но я не думаю, что функция asp должна выходить за рамки настройки переменных среды и должна быть сохранена таким образом по соображениям совместимости.

@wnkz, это было в случае с более ранней версией плагина AWS, он был недавно изменен (не уверен, почему, я заметил это только когда вытащил основную ветку)

@robvadai

Таким образом, он переключает профиль при сбое

Фактически он не переключал профиль - он устанавливал переменные среды. Это могло бы лучше обрабатывать ошибки, достаточно справедливо. Я посмотрю, что можно сделать.

@wnkz

Я не возражаю против использования разных функций для MFA и прочего, но я не думаю, что функция asp должна выходить за рамки настройки переменных среды и должна быть сохранена таким образом по соображениям совместимости.

Не уверен в этом - цель asp - переключить профиль, а не устанавливать переменные среды, верно?

но проверки только атрибута role_arn недостаточно для запуска "ручного" принятия роли.

@wknz Почему ты так говоришь? Можете ли вы назвать какие-либо другие причины иметь role_arn в конфигурации вашего профиля?

@wknz Я еще раз прочитал ваше описание и могу подтвердить, что это не ошибка. Предполагая, что роли IAM - это то, как AWS рекомендует защищать доступ к вашим ресурсам: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#delegate -using-roles

Если это не то, что вы хотите, вы совершенно справедливо намекнули на обходной путь: удалите role_arn из ~/.aws/config для тех профилей, которые не требуют принятия роли.

Тем не менее, это не работает, по крайней мере, если включен MFA, который должен быть стандартным для всех.

Тем не менее, это не работает, по крайней мере, если включен MFA, который должен быть стандартным для всех.

@robvadai Я сейчас проверяю ваше дело. В идеале у меня было бы это в другом баге (так как вывод по исходному выше), но я все равно проверю.

А пока могу сказать, что в моей компании более 20 инженеров успешно используют его с MFA. Так что в вашей настройке должно быть что-то особенное, что я проверяю.

Я ценю это, однако я пробовал его на учетных записях AWS для 2 компаний (я консультант) и не работал ни для одной из них - это 2 компании, географически расположенные в разных местах и ​​совершенно разный персонал, поэтому маловероятно, что те же люди создали свою учетную запись AWS.

@robvadai , я ищу. Между тем, что общего между этими двумя компаниями, в которых вы работаете консультантом? Вот почему я очень хочу проверить, как _you_ это делает. 👍

А пока вот скриншот использования плагина в одной из четырех моих учетных записей AWS:

Я подозреваю, что наши учетные данные настроены иначе. Не могли бы вы поделиться своими ~/.aws/credentials и ~/.aws/config для профилей default и dev_admin_cli ? Конечно, замените ключи доступа на ABC и т. Д.

@robvadai
Есть ли шанс, что вы могли бы поделиться своими ~/.aws/config , вычеркнув все номера счетов и названия компаний?

Вот мой, с одной из машин, в качестве примера:

:-D

И учетные данные:

Хорошо, я не использую mfa_serial и external_id что это? Эта проблема может быть решена некоторыми инструкциями в README :)

@robvadai Возможно, вы правы насчет README.

Итак, mfa_serial - это зарегистрированный ARN устройства MFA для выполнения MFA. Если его не существует, сценарий проигнорирует его.

А external_id - это просто необязательный дополнительный уровень безопасности - он необходим только в том случае, если вы хотите иметь дополнительный общий секрет между тем, кто берет на себя роль, и тем, кто ее устанавливает. Это совершенно необязательно, и плагин не требует, чтобы он работал.

Я пытаюсь понять, как вы принимаете на себя роль - не похоже, что в вашем случае настроен МИД, верно? Похоже, ваша учетная запись может выполнять некоторые роли без дополнительной авторизации? Какой для этого вариант использования?

Мы не разрешаем входить в систему или принимать какие-либо роли без MFA в соответствии с передовыми практиками AWS, поэтому мы стремимся разобраться в этом примере использования.

Хорошо, поэтому я переключаюсь на роль, использую этот сценарий aar для запуска аутентификации MFA, а затем снова переключаюсь на другую роль. Конечно, это было в случае со старой версией плагина AWS, и я не знал о его новых функциях. Позвольте мне изменить мою конфигурацию и вернуться к этому.

Спасибо, @robvadai ! А пока я попробую придумать вариант использования, подобный вашему.

На основании предоставленного вами сообщения об ошибке:

An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:iam::11111111111:user/original_user is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::9999999999999:role/myrole

user/original_user не имеет права предполагать role/myrole .

Глядя на код, поведение aar и нового asp должно быть идентичным. Вот строка из aar которая, по вашему мнению, удалась для вас:

local credentials_output=$(aws sts assume-role --role-arn ${role_arn} --role-session-name ${session_name} --query '[Credentials.AccessKeyId,Credentials.SecretAccessKey,Credentials.SessionToken]' --output text | tr "\t" "\n")

Это строка из asp которая, по вашему мнению, вам не подходит:

local assume_cmd=(aws sts assume-role "--profile=$profile" "--role-arn $role_arn" "--role-session-name "$profile"" "$mfa_opt" "$extid_opt")

В обоих случаях:

• role-arn будет таким же
• role-session-name будет отличаться от -session в конце имени профиля (и это действительно не имеет значения)
• оба mfa_opt и extid_opt будут пустыми

Таким образом, обе команды должны выполнять одну и ту же фактическую команду.

Хотя я должен сказать, что сценарий дал мне представление о том, как избавиться от jq как зависимости для работы asp . Хороший.

Изменил мою конфигурацию, протестировал для одного профиля и работает без дополнительного скрипта aar !

Однако, когда я не ввел продолжительность сеанса, я получил:

Please enter your MFA token for arn:aws:iam::1111111111:mfa/myuser:
123456
Please enter the session duration in seconds (900-43200; default: 3600, which is the default maximum for a role):

asp:31: command not found: sess_duration
Assuming role arn:aws:iam::11111111111111111:role/muyser using profile AAAAA
usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:

  aws help
  aws <command> help
  aws <command> <subcommand> help
aws: error: argument --duration-seconds: expected one argument
Switched to AWS Profile: AAAAA

Спасибо за подтверждение и рад, что это сработало! Я проверю, почему он так себя ведет, с продолжительностью сеанса для вас. Идея состоит в том, что если вы просто нажмете Enter, не вводя длительность сеанса, будет использоваться значение AWS по умолчанию, потому что переменная продолжительности сеанса пуста.

Не могли бы вы поделиться подробностями о системе, в которой вы ее используете? В частности, что это за ОС и в какой версии zsh (самой оболочки) вы ее используете? Спасибо!

Да все хорошо сейчас, просто еще одна вещь: мне нужно [profile PROFILENAME] , так что profile Приставка в config файла в то время как credentials файл не нужен. Java SDK тоже жалуется на этот префикс - не могли бы вы изменить скрипт, чтобы нам не нужен этот префикс profile ?

@maksyms macOS 10.15.7 (19H2)
Версия ZSH zsh 5.7.1 (x86_64-apple-darwin19.0)

Да все хорошо сейчас, просто еще одна вещь: мне нужно [profile PROFILENAME] , так что profile Приставка в config файла в то время как credentials файл не нужен. Java SDK тоже жалуется на этот префикс - не могли бы вы изменить скрипт, чтобы нам не нужен этот префикс profile ?

Это не я - это стандартный интерфейс командной строки AWS, а не я, который помещает [profile PROFILENAME] в файл конфигурации, поэтому не уверен, чем могу помочь. Старый asp ожидал того же.

Однако, когда я не ввел продолжительность сеанса, я получил:

Я воспроизвел это. Это ошибка, @robvadai. Не могли бы вы сообщить об этом как единое целое и отметить меня в отчете? Затем я могу посмотреть, как это исправить.

@wnkz

Я не возражаю против использования разных функций для MFA и прочего, но я не думаю, что функция asp должна выходить за рамки настройки переменных среды и должна быть сохранена таким образом по соображениям совместимости.

Не уверен в этом - цель asp - переключить профиль, а не устанавливать переменные среды, верно?

но проверки только атрибута role_arn недостаточно для запуска "ручного" принятия роли.

@wknz Почему ты так говоришь? Можете ли вы назвать какие-либо другие причины иметь role_arn в конфигурации вашего профиля?

@maksyms Меня очень смущают твои вопросы 🤔
Вы когда-нибудь читали https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html ?

role_arn + source_profile - это самая простая настройка для использования ролей с AWS CLI. Я не использую его часто, но он может обрабатывать MFA, если я правильно помню.
В этой конфигурации AWS CLI автоматически принимает роль, настроенную в профиле, кэширует учетные данные и обновляет их при необходимости.

Когда вы используете роль, интерфейс командной строки AWS кэширует временные учетные данные локально, пока срок их действия не истечет. В следующий раз, когда вы попытаетесь их использовать, интерфейс командной строки AWS попытается обновить их от вашего имени.

Чтобы указать AWS CLI, какой профиль использовать, можно использовать флаг --profile или переменные среды AWS_PROFILE .
IMHO, функция asp используется только для перечисления существующих профилей и простой установки переменных среды, чтобы AWS CLI мог выполнять остальную работу за вас, как задумано .

Теперь с обновленной функцией роль принимается вручную, учетные данные хранятся в переменных среды и никогда не обновляются. Более того, немедленное принятие роли вызовет проблемы с другими типами более сложных конфигураций с использованием credential_process или AWS SSO из CLI v2.

Я действительно не хочу показаться грубым, но это изменение доставило мне только проблемы. Я действительно не знаю, что заставило вас это сделать, и это может быть прекрасным вариантом использования, но для меня это критическое изменение, и его следует, по крайней мере , реализовать в новой функции, но не заменять существующую.

👋

@wnkz Большое спасибо за подробное

Мне жаль, что вы считаете, что изменение доставило вам проблемы. Судя по реакции нескольких других людей, изменение уже упростило их рабочие процессы - и это в дополнение к примерно 30 пользователям, которые использовали это изменение до его объединения.

Причина внедрения изменения точно связана с указанной вами документацией (https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html).

Назначение asp - включить запуск AWS CLI и многих других команд (в нашем случае, kubectl и производных, например) в контексте определенного профиля, предполагая определенную роль, в все или, по крайней мере, без необходимости указывать длинные командные строки. В случаях, когда принудительно применялся MFA, это было невозможно сделать со старым asp . С этим обновлением это возможно.

Очень конкретный пример использования выглядит следующим образом:

1. Я пользователь AWS IAM maksyms в корневом аккаунте AWS
2. Мне не разрешено запускать какие-либо команды в интерфейсе командной строки AWS, кроме принятия на себя определенной роли.
3. После того, как я беру на себя роль (включая роль кросс-аккаунта), я могу запускать любые команды, которые мне нужны, в контексте этой роли. Один из примеров: kubectl

Вот иллюстрация:

Вот что здесь происходит:

1. Никакая роль не предполагается, просто профиль устанавливается путем установки переменной окружения AWS_PROFILE
2. Переход к правому контексту K8s
3. Пытаюсь получить список модулей - как видите, AWS CLI не может взять на себя роль
4. Вызов обновленного asp для выполнения MFA и принятия роли вместо простой установки переменной среды AWS_PROFILE
5. Успешно перечисление стручков
6. Очистка профиля с помощью asp (который просто очищает переменные среды!) И повторная установка AWS_PROFILE на правильный профиль (что вы отстаиваете)
7. Не удалось получить список модулей, так как интерфейс командной строки AWS не может взять на себя роль

Надеюсь, это более подробно объясняет проблему, которую решает этот PR.

Теперь вернемся к вашему варианту использования.

Основываясь на вашем описании, я _угадываюсь_, что вы предпочитаете использовать AWS CLI, каждый раз указывая --profile или задавая переменную среды, используя "тупой" asp а затем имея AWS CLI разберется с остальным. Как видите, kubectl , а также некоторые другие инструменты в этой ситуации не работают.

asp - это способ переключения профилей, а не только установка переменных среды.

Мне интересно, как лучше всего тебе помочь. Какие-либо предложения помимо отмены изменения?

🙏 Пожалуйста, сопровождающие, прочтите это, прежде чем объединять что-либо в этом плагине.
@ 53jk1 @mcornella Я упоминаю вас, потому что вы просмотрели и объединили предыдущие PR.

Изменение # 8419 плохо по нескольким причинам:

• Это внезапное изменение
• В лучшем случае это бесполезно, потому что эта «функциональность» должна быть реализована в самих AWS SDK (и, следовательно, в AWS CLI).

@maksyms

Единственное, что я увидел в этом изменении, - это то, что мой ежедневный рабочий процесс полностью нарушен, и я почти уверен, что я не единственный.
Я очень ценю, что кто-то внес свой вклад в этот плагин, но это плохая разработка программного обеспечения.

Я понимаю вашу проблему с такими инструментами, как kubectl ; подобное происходит с terraform при использовании MFA.
Но опять же, эти инструменты отвечают за использование правильных версий AWS SDK, которые должны считывать общий формат конфигурации и автоматически принимать роли с использованием MFA или без него.

Новая функция asp работает только для вашего конкретного случая использования и полностью игнорирует рабочие процессы с использованием различных инструментов (например, aws-okta, aws-vault, ...).

Я видел это, потому что обновляю oh-my-zsh ежедневно, но могу гарантировать, что многие пользователи AWS очень скоро разозлятся, обновив oh-my-zsh. Это единственное изменение, которое заставило меня вручную откатить oh-my-zsh за многие годы.

Мое предложение найти компромисс:

• вернуть функцию asp к тому, что было раньше (что вы называете тупым)
• переименуйте текущую функцию asp во что-то новое, например asp-mfa или что-то еще.

@wnkz Так получилось, что вы разговариваете с недавним сопровождающим.

1. Не знаете, как вы себе представляете «анонсированное» изменение в подобном программном инструменте? Было бы хорошо услышать твои мысли.
2. PR был доступен любому желающему около 1 года. Несколько человек прокомментировали. Никто не поднимал этот вопрос. Я не говорю, что это не важно - я просто говорю, что мне сложно понять, как можно собрать больше отзывов.
3. Если у вас есть выбор: обновить много "сломанных" инструментов и обновить один плагин, который может позаботиться об этом, какой подход более прагматичен?

Хорошо, позволь мне подумать об этом.

Еще одна мысль: будет ли добавление некоторой переменной env, чтобы указать, принимать на себя роль или нет, может быть вариантом?

Пять часов назад вас произвольно объявили сопровождающим, поэтому, пожалуйста, сохраняйте спокойствие и уберите карточку "сопровождающего".
Мы все люди, обсуждающие программное обеспечение. Мне очень жаль, если я обидел твои чувства; в моих комментариях о внесенных вами изменениях нет ничего личного .

1.

Что ж, это основная передовая практика разработки; вы не можете внезапно полностью изменить поведение инструмента / функции / метода, не предупредив пользователей и не предоставив должного времени для адаптации или поиска обходных путей. Если вам отчаянно нужно внести изменения, по крайней мере, добавьте новую функцию с новым именем, но не заставляйте людей использовать ваше решение. С моей точки зрения, вы просто сломали что-то, чего не было без решения, кроме отката к предыдущей версии. Я не говорю, что это бесполезно для всех, но то, что это полезно для 30, не означает, что это для всех остальных.

2.

То, что ПР №8419 был открыт более года назад, не имеет никакого значения. Я должен взглянуть на запросы на включение oh-my-zsh не потому, что я являюсь пользователем oh-my-zsh или этого плагина. Я не знаю, сколько OSS вы используете, но уверен, что вы не просматриваете все запросы на вытягивание, открытые в каждом из этих репозиториев.

3.

Опять же, вы пытаетесь исправить что-то, что не сломано. Конечно, заставить все сторонние инструменты правильно использовать AWS SDK будет сложно, если не невозможно, но это единственный разумный способ сделать это.

В заключение, если бы вы просто добавили новую функцию с новым именем и сказали бы всем, у кого возникла ваша проблема, использовать ее вместо asp у нас бы никогда не было этого обсуждения; ваша проблема все равно будет решена, и мой рабочий процесс (и один из многих других) не будет нарушен.

Я не думаю, что буду уделять больше времени обсуждению этого, поскольку я представил большинство своих аргументов. Прямо сейчас этот плагин для меня бесполезен, поэтому либо вы как новый сопровождающий сделаете с ним что-нибудь, либо я верну исходную функциональность в другом плагине.

Хорошего дня

@wnkz Вы правы, мы обсуждаем программное обеспечение, и моя единственная цель - помочь улучшить эту функциональность для сообщества, а не только для вас или меня. Большинство ваших предложений неконструктивны и их невозможно реализовать в данном конкретном случае; ваш тон звучит агрессивно, подход кажется идеалистическим, а поведение - демагогическим. Хотя я понимаю, что вы расстроены тем, что изменение в коде с открытым исходным кодом, которое вы загружаете ежедневно, нарушило ваш рабочий процесс, оно не оправдывает токсичное поведение. Я предлагаю прекратить это сейчас.

До сих пор я пытался сосредоточиться на понимании и решении конкретной проблемы, которую вы поднимаете, которая мешает вашему рабочему процессу, а не на тоне этого разговора. Одно конструктивное предложение, которое я слышал от вас, - это ввести функцию с другим именем для выполнения ролей. Хорошо, возможно, поскольку эта фиксация была выпущена недолго, это разумный путь вперед. Сейчас буду реализовывать.

Всем привет,

он отлично работает, когда я использую роль, но больше не запрашивает MFA для исходного профиля.

Я добавил mfa_serial в свой исходный профиль.

Таким образом, в этом исходном профиле есть mfa_serial но явно не role_arn и source_profile .

Любая идея?

https://github.com/maksyms/oh-my-zsh/blob/a656e4ea4fe4e715ab12265f54f03c7db52cf8b5/plugins/aws/aws.plugin.zsh#L49

Это проблема.

Для исходных профилей у нас нет role_arn .....

Я исправил это, но в коде есть некоторые дублирования, нужно привести его в порядок: https://github.com/ohmyzsh/ohmyzsh/compare/master...robvadai : bugfix / aws-mfa-with-source? Expand = 1

Кстати, пропуск времени все равно приводит к ошибке:

acp myprofile
Please enter your MFA token for arn:aws:iam::1111111111:mfa/myuser:
123456
Please enter the session duration in seconds (900-43200; default: 3600, which is the default maximum for a role):


An error occurred (AccessDenied) when calling the GetSessionToken operation: MultiFactorAuthentication failed, unable to validate MFA code.  Please verify your MFA serial number is valid and associated with this user.
Switched to AWS Profile: myprofile

@robvadai Не могли бы вы зарегистрировать это как отдельную проблему и поделиться своей конфигурацией и учетными данными? Я не уверен, что понимаю, что вы имеете в виду, когда говорите «для исходных профилей у нас нет role_arn» - я тоже не понимаю.

Причина, по которой вторая проблема, когда вы не указываете продолжительность сейчас, заключается в том, что аутентификация MFA не выполняется, а не по какой-либо другой причине - так что это не связано с плагином.

https://github.com/ohmyzsh/ohmyzsh/issues/9409

https://github.com/ohmyzsh/ohmyzsh/issues/9408